DDD не описывает где вам хранить вашу логику
но для DDD лучше всего подходит паттерн CQRS
вы конечно можете логику разместить в классах, которые моделируют сущности и агрегаты
практика показывает, что такой подход неэффективен
используя CQRS, любое изменение производится с помощью команд
с помощью отдельных запросов вы можете вытаскивать проекции данных, но не сами сущности или агрегаты
по сути, единственный способ достать агрегат, это вытащить его по ID
единственный способ создать, изменить или удалить агрегат, это выполнить команду
команда это не любая логика вообще, это конкретно внесение изменений в систему
бизнес-логика при этом размещается в службах и сервисах
очередной поток сознания от местного "эксперда", нагугленные умные слова сваленные в кучу без малейшей попытки осмысления и опыта практического использования
CQRS напрямую к DDD вообще не относится, это разные вещи и идея использовать CQRS только потому, что используется DDD может родится только в воспаленном гуглом уме. CQRS нужен когда модели для чтения начинают разнится с моделями для изменения, также изоляция чтения позволяет маштабировать ее независимо от записи и прочее, все это обусловлено требованиями к конкретной системе, а никак не использованием DDD
А бизнес-логика в классическом DDD как раз расположена в сущностях, вынесение ее в отдельные классы сервисов будет уже называться анемичной моделью и не являтся DDD как таковой. "Практика" у него показывает что это неэффективно Для фриланс интернет-магазина по продаже валенок или студенческого проекта - возможно, а в коммерческих проектах люди сначала анализируют требования к системе, а уже потом принимают решения
love_bachКак-то не интуитивно, часть логики в корне агрегации, часть не там?
А как там разруливается, например, что есть уже такой агрегат? Уникальность в БД. Где это должно быть?
за уникальность отвечает владелец данных (т.е. база), к функциям DDD это не относится
