DDD основное, что нужно помнить

В предметно ориентированном дизайне задачу построения архитектуры приложения можно разделить на две части "Стратегическую" и "Тактическую".

Стратегия

Определяется решением следующих вопросов:

- Выделением общего языка
- Созданием пользовательских историй
- Выделение домена приложения

При этом для архитектур с централизованным хранилищем данных DDD чаще бывает излишним, чем полезным, DDD стоит рассматривать если у вас минимум 30-40 пользовательских историй.

Стратегия оправдывает себя даже если вы не реализуете конкртеные шаблоны DDD в коде, так как позволяет прийти к единому пониманию предметной области, отделить бизнес термины от технических терминов.

Тактика

Включает в себя реализацию шаблонов для организации объектной модели приложения. В первую очередь выделяются слои приложения (от внутреннего к внешнему):

- Entities, Value objects, Domain Events, Aggregates
- Repositores, Domain Services
- Application services
- UI

Aggregate

Агрегаты - это абстрактное понятие, которое на диаграммах можно представить как "границу" всех сущностей (entities) и объектов значений (value objects), а в коде агрегат представлены "корнем агрегата", который как правило является сущностью, включающей в себя другие сущности.

Value Object vs Entity

Чтобы лучше понять когда что создавать помните:

- идентификация сущности делается по Id, value object идентифицируется всеми своими полями
- сущность имеет маскимально длинный жизненный цикл, объекты значения наоборот имеют очень короткий жизненный цикл
- сущности могут изменять свой стейт (спорно, но в целом так), объекты значения только создаваться новые, изменять старые не принято
- логика в объектах значениях обычно простая (объект делается "легким"), в отличии от сущностей


Domain Service

Чаще всего в доменные сервисы размещается общая логика, которую сложно связать с сущностями. Обычно доменных сервисов стараются много не создавать.

Репозиторий

Во многом это чисто техническое решение для того, чтобы инкапсулировать (не обязательно скрыть, но собрать вместе) логику свзяывающую СУБД и приложение, в сущностях не должно быть логики сохранения в БД. Плюс репозитории отвечают за создание коллекций сущностей.

Репозиторий - "один ко многим", может включать логику массовых операций.
Сущность - "один к одному", включает бизнес-логику и стейт.


#DDD #знания #теория