Смутно о ограниченных контекстах и субдоменах

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

Из того, что мне удалось перегонять, должна существовать связь 1:1 между BC и SD. Тем не менее, я читал в других местах, что это не обязательно так.

Может ли кто-нибудь объяснить мне связь между BC и SD?

Ответы

Ответ 1

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

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

Ответ 2

Я пытаюсь объяснить эти понятия своим пониманием.

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

Домен в DDD представляет собой реальную проблему в бизнесе. Например: электронная коммерция - это домен, система расчета заработной платы - это домен
Домен разделен на многие поддомены, поэтому в каждом поддомене сосредоточены более мелкие проблемы. Например: E commerce имеет множество поддоменов, таких как: Корзина, Биллинг, Каталог продуктов, Информация о клиенте...
Каждый субдомен должен иметь четкие обязанности, поэтому у него есть граница для ограничения их функциональности, граница поможет фокусу субдомена делать только одно дело и преуспеть. Эта граница рассматривается как ограниченный контекст поддомена. Ограниченный контекст будет определять:
- Сколько доменных моделей необходимо для поддомена?
- Какие свойства необходимы в каждой модели?
- Какие функции необходимы в поддоне?

Пример: для моделей подкатегорий корзины для покупок: Корзина, Продукт, Информация о клиенте... и содержит функции для выполнения CRUD на тележке. Примечания. Модель продукта и клиента в дополнительном домене корзины покупок, возможно, не совпадает с моделями в подкаталоге Product Catalogs и Customer Profiles, они содержат только необходимые свойства для отображения в корзине покупок.

Ответ 3

Перечитывая контекст бронирования из синей книги 18 раз, я помог мне наконец получить ручку. http://codeidol.com/csharp/domain-driven-design/Maintaining-Model-Integrity/Bounded-Context/

Эта статья также помогла: http://gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/

Ответ 4

Пожалуйста, проверьте эту ссылку, это поможет вам, Ограниченный контекст или контекст? Термин "контекст" - это общее описание группы понятий, термин "ограниченный контекст" более конкретен - "ограниченный контекст" - это область вашего приложения, которая имеет явно определенные границы, имеет свою собственную модель и поддерживает собственный код. В ограниченном контексте все должно быть строго согласованным.