По совету знакомого прочитал книгу Learning Domain-Driven Design

Могу сказать, что это очередная книга, которая перевернула моё сознание как разработчика.

Основные моменты, которые я вынес для себя из этой книги:

1⃣ Если пишете новый проект и он сложнее Hello World, то нет никаких причин по которым вам следует использовать Anemic Domain Model. Почему? По моему опыту, когда используется анемичная модель (т.е. разделение данных и логики), то вся бизнес логика размазывается по всевозможным сервисам, которые могут иметь название Services, Utilities, Managers, Engines, Handlers и т.д. Кто-нибудь мне может сказать не глядя в код, в чем различие Service от Manager или от Handler? В DDD есть чёткое разделение слоев и функционала со своими naming conventions. По идее, перейдя в другой проект с DDD ты сходу разберёшься какой код за что отвечает.

2⃣ Вытекает из предыдущего пункта. Если у нас анемичная модель (т.е. класс это набор get и set), то со вероятностью 99.9% у нас повсюду мапперы. Мы же хорошие программисты и не любим high coupling, а значит надо, например, разделить слой данных от доменного слоя через маппинг. В качестве примера приведу реальный сценарий чтения данных на одном и проектов где я работал:
0. Данные читаются из БД в Database Object (DBO).
1. DBO маппится в доменную модель.
2. Доменная модель доходит до контроллера и там маппится в Data Transfer Object (DTO)
3. Клиент принимает результат HTTP запроса и парсит JSON в свой DTO.
4. Затем клиент маппит клиентский DTO в клиентскую доменную модель.
В итоге, имеем: DBO, серверную доменную модель, серверный DTO, клиентский DTO, клиентскую доменную модель. Все классы содержат примерно одинаковый набор свойств и весь этот зоопарк надо поддерживать, а это только GET запрос. Представьте что будет для POST?

3⃣ Переход от Anemic Domain Model к Rich Domain Model естественным образом приводит проект к Event Sourcing и CQRS. Почему так происходит? Потому что если доменная модель содержит логику, то нужно что-то, что будет вызывать эту логику. В дело сразу же вступают команды, а за ними и события, а если проект относительно сложный, то появляются хранилища событий, проекции и т.д.

✍ Книга в целом понравилась. Хочу закрепить свои знания в области DDD, поэтому в скором времени планирую опубликовать целый цикл статей по этой теме.