Концепции проектирования на основе домена и связь с CQRS

Question

Недавно я начал знакомиться с концепциями DDD и CQRS, и я понял, что одной из наиболее важных концепций в CQRS является DDD помимо балансировки нагрузки, NServiceBus и т. Д., Но мне любопытно, можем ли мы использовать концепцию DDD в одиночку, не используя ее в CQRS сложность для разработки и создания нашего проекта. Насколько я знаю, это подход к разработке программного обеспечения для сложных нужд путем подключения реализации к развивающейся модели. Мне нужно знать, сколько должна быть масштаб проекта для использования DDD отдельно или с CQRS.

Answer 1

В качестве дополнения к ответу @ расширяемого:

CQRS, агрегаты, источники событий и т. Д. Являются всего лишь инструментами.Опыт показывает, что они хорошо работают в проектах DDD.Использование этих инструментов не означает, что вы делаете DDD.

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

Например, вы можете подумать о жизненном цикле продукта для интернет-магазина (например, Amazon).После обсуждения с экспертами в области вы обнаружите, что Продукт имеет различное значение в зависимости от жизненного цикла покупки.Для розничного контекста продукт - это цена и описание, тогда как в контексте доставки важны адрес назначения, а также размер и вес продукта.

Это подсказка о том, что используются два языка, и что вам, вероятно, придется создавать ограниченный контекст для каждого (розничная торговля и доставка).Ограниченный контекст представляет область домена, в которой используется один язык.Границы контекста появляются, когда значение слов языка начинает меняться.

Ограниченные контексты, определенные после обсуждения между разработчиками и экспертами предметной области, должны быть согласованы с базой кода.В этом примере вы, вероятно, создадите пакет для розничной продажи, а другой - для доставки.Реализация ограниченного контекста обычно довольно сильно отделена друг от друга.Например, каждый ограниченный контекст будет иметь свой собственный класс продукта с различными свойствами.

Каждый ограниченный может иметь свою собственную архитектуру: CQRS, Event Sourcing, Hexagonal и т. Д., В зависимости от потребностей.Однако вы должны быть осторожны, чтобы выбранная вами архитектура хорошо соответствовала домену ограниченного контекста.Например, вы, вероятно, не будете использовать источник событий, если ваш домен сам по себе не основан на событиях.

Answer 2

Краткий ответ: да, вы можете.

CQRS как архитектурный стиль появился после DDD.Он основан на Разделение команд-запросов (CQS) .

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

• Опция 1 : компромисс для вас Модель домена для удовлетворения этого требованиянужно и сделать его более подходящим для чтения.

• Вариант 2: Полностью разделите два, как это делает CQRS.Сохраняйте хорошую модель записи, которая представляет ваш домен, и в то же время используйте модель чтения, которая показывает, как вы хотите, чтобы ваши данные отображались пользователю.

• Опция3 Создайте свой пользовательский интерфейс / интерфейс, чтобы не показывать все данные одновременно.Например, возьмем способ, которым пользовательский интерфейс в телефонах работает.Так как они имеют меньшие экраны, более медленный процессор и меньше оперативной памяти, а самое главное: батарея, которая постоянно разряжается, они обычно показывают небольшую часть данных, а затем вам нужно переходить, чтобы увидеть больше.Делайте один запрос за другим вместо огромного и покажите все на одном экране.Вы можете противопоставить это настольным приложениям, которые имеют богатые меню, и при их открытии показывают множество вещей.

Это создает дополнительную сложность, которой вы, возможно, не захотите управлять, поэтому выможет выбрать вариант 1 или 3 в зависимости от вашей организации (заставить людей проектировать пользовательский интерфейс таким способом может быть сложно, поэтому вы можете пойти на вариант 1 в качестве компромисса).

По моему опыту, если вы не разрабатываете приложение, которое будет обрабатывать данные от большого количества пользователей (скажем, 200 000, и даже тогда это может быть хорошо), вы можете пропустить CQRS.Если у вас возникла эта проблема позже, вы всегда можете изменить ее.Наличие единственной симпатичной доменной модели облегчает последующее внедрение CQRS.

Если вы не читали книгу DDD , я настоятельно рекомендую ее.

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

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

Примените некоторый начальный анализ и посмотрите, принесет ли CQRS какое-либо значение.Если это действительно начинается с этого.Если этого не произойдет, начните без него.Если вы новичок в DDD и CQRS, лучше не начинать с обоих в одном приложении, так как вы можете столкнуться с неожиданной сложностью и оказаться в сложной ситуации.Начните с DDD, приобретите в нем опыт, а затем вы можете попробовать CQRS.