Домен-привод-дизайн против шаблона команды - взаимоисключающий?

Question

Т.Л., д-р:
Я люблю маленькие, сфокусированы классы командно-паттерна, такие как SetProjectAsActiveCommand, но я также подход для DDD создания моделей, отвечающие за их собственные основную бизнес-функции, такие как вызов Project::setAsActive(). Могут ли две идеи работать вместе или они являются взаимоисключающими архитектурами?
/Т.Л., др

Я работаю над проектом в течение последних нескольких месяцев, в которых мы использовали шаблон Command, который имеет классы, как ProposeNewProjectCommand, SetProjectAsActiveCommand и AddCommentToProjectCommand, все из которых обрабатываются командной шиной. Эти классы, как правило, довольно малы и сосредоточены, делая только одно.

Недавно я читал о Domain-Driven-Design (DDD) и я понимаю, что такой подход опирается в большей степени на модели делают работу сами, поэтому команды выше, могут быть заменены Organisation::proposeNewProject(), Project::setAsActive() и Project::addComment().

Имея эти методы на модели означает, что они могут действовать как «агрегированные корни» (например, в приведенных выше примерах, Project отвечает за создание своих собственных комментариев).

Хотя мне очень нравится идея, что мои сущности больше несут ответственности за свои основные бизнес-функции, я также обеспокоен тем, что мои модели могут действительно быть действительно большими, с множеством методов на них, относящихся к различным вещам, которые приложение может делать.

Есть ли способ иметь небольшие, сосредоточенные классы шаблона Command, в то же время делая модели первоклассных граждан ответственными за их ключевые бизнес-функции, такие как DDD? Или способ решить потенциальную проблему большой модели?

Или, в качестве альтернативы, следует выбрать один шаблон и использовать его исключительно?

Заранее спасибо за любую проницательность вы можете дать,
Харрисон

PS. Я никогда не работал над приложением, использующим DDD, поэтому извиняюсь, если это невероятно наивный вопрос.

Answer 1

Я бы сказал, что они могут быть абсолютно использованы вместе. Фактически, мы используем эту комбинацию с большим успехом в наших текущих проектах.

Вы правы, что обработчики команд мелкозернистые, а модели DDD более сплочены. Однако эти обработчики команд могут свободно выполнять команду различными способами, будь то DDD или сценарий транзакций. Вы можете использовать любой подход, имеющий смысл для данной команды/варианта использования. Таким образом, вы не блокируете использование DDD для каждой команды (иногда вам просто нужна простая вставка без участия модели).

Ваши модели DDD могут использоваться совместно на вашем командном уровне. Например, у вас может быть 5 команд клиента, которые работают на одном объекте модели DDD Customer.

Answer 2

Что делает его DDD, это то, что вы начинаете думать о языке больше, что вы пытаетесь добраться до модели в коде, который «синхронизирует» с вашим пониманием домена. Фактические шаблоны реализации - это детали реализации.Например, мы можем попробовать, если есть еще лучшие способы выражения команд, например SetProjectAsActiveCommand -> ActivateProject; AddCommentToProjectCommand -> CommentOnProject. Мы избавляемся от языка разработчика (set, add, command) в пользу языка домена.

Команды в этом подходе ничего не делают (они не похожи на команды GoF). Это просто сообщения, представляющие намерение пользователя. Агрегаты (и объекты, объекты ценности, ...) представляют нашу модель структурной области. Они знают, как делать вещи, принимать решения, защищать бизнес-правила ... Между этими сообщениями и принятием решений должно быть что-то, что получает сообщение и переводит его в модель домена. Это обработчики команд: они довольно глупы, они просто убеждаются, что сообщение достигнет нужной совокупности. Очень часто обработчик команд делает не что иное, как извлечение агрегата из репозитория и говорит ему что-то делать, не понимая внутренних дел. Это аккуратно отделяет команды от модели домена.

Возможно, вы можете сказать, что я большой поклонник этого стиля организации кода. Я думаю, что это очень полезно для DDD. Вы можете применять DDD многими другими способами. В конце концов, цель заключается не в том, чтобы «делать DDD», а в создании систем, которые решают проблемы, являются проверяемыми и поддерживаемыми и эволюционирующими.