DDD - Несколько ограниченных контекстов из-за различий совокупных данных?

Question

Мы пытаемся разделить наш домен на ограниченные контексты с целью иметь модульный дизайн / архитектуру приложения.

Мы провели просвещающий сеанс EventSorming, который нам очень помог выявить ограниченный контекст и его агрегаты.После семинара каждый участник согласился с определенным ограниченным контекстом.

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

Мы также идентифицировали агрегаты, такие как «Контракт».Каждый контракт почти повторяет один и тот же процесс, , но объем данных, содержащихся в этих контрактах, может существенно различаться.Существуют очень простые типы контрактов и типы контрактов, которые включают много дополнительных данных и вложений.

Имеет ли смысл объявлять другой ограниченный контекст только потому, что данные агрегата более сложны?

Оба подхода имеют свои недостатки:

1. Реализация всех типов контрактов в одном ограниченном контексте может привести к большому количеству if-операторов в коде для обработки различных данных.
2. Извлечение нового ограниченного контекста может привести к появлению большого количества дублирующегося кода только из-за того, что некоторые данные различаются.

Любые предложения / лучшие практики, как с этим справиться?

Answer 1

• Нет конкретных бизнес-команд для различных типов контрактов
• Нет специальной команды разработчиков для определенных типов контрактов
• Один и тот же вездесущий язык используется для всех контрактов
• Каждый контракт почти повторяет один и тот же процесс

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

Answer 2

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

BC не идентифицируются процессами, BC связаны с языком.Каждый БК имеет свой собственный вездесущий язык (UL).BC - это контекст, в котором понятие имеет значение.В любом случае БК принадлежат пространству решения.Прежде всего вы должны исследовать домен (проблемное пространство) и разбить его на поддомены, перегоняя основной домен.Затем вы моделируете каждый поддомен.BC - это контекст, в котором живет модель.В идеале отношения между поддоменами и BC должны быть 1: 1.

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

Таким образом, идентификация поддоменов связана не с процессами, а спонятия и UL.

Имеет ли смысл объявлять другой ограниченный контекст только потому, что данные агрегата являются более сложными?

Нет, вы не должны создавать произвольные BC просто потому, чтоагрегаты сложны.BC основаны на UL.

Какие-либо предложения / лучшие практики, как с этим справиться?

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

Answer 3

Ограниченный контекст имеет мало отношения к операторам if, поэтому я не уверен, что вы имеете в виду.

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

Кроме этого, вы можете иметь любой дизайн внутри контекста.Я чувствую, что количество выражений if больше зависит от вашего класса / дизайна кода, например, правильно ли вы используете полиморфизм, интерфейсы и тому подобное.

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