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 #знания #теория