Как представить ограниченный контекст?

Ответ 1

Я бы сказал "это зависит"

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

IMO, электронная коммерция может быть скорее BC, чем полным доменом.

Я потратил слишком много времени на целый торговый агент, где они продавали продукты питания.

Таким образом, домен был "целыми продажами", а ограниченными контекстами были: инвентаризация, покупка, продажа, выставление счетов, каталог товаров и электронная коммерция (возможно, я использую неправильную английскую формулировку здесь)

Каждый из этих БК знал о "продуктах", но все они имели разные взгляды на продукт.

например. Покупка может включать в себя объект продукта с информацией о продавце, покупной ценой и т.д.

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

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

Таким образом, репозиторий продуктов в электронной коммерции BC может выполнять контекстное сопоставление из другого BC (через службы какого-то рода, скорее всего, web или wcf в моем случае), чтобы построить продукт для своей электронной коммерции)

Лично я моделирую это как отдельные сборки, у меня будет модель электронной коммерции и модель продаж.

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

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

Короче говоря, я склонен строить свои системы вокруг конкретного ВС и взаимодействовать только с другими службами BC через сервисы.

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

Ответ 2

Я, конечно, согласен, что все зависит от этого, но есть некоторые рекомендации, которые могут/должны соблюдаться. Цель ограниченных контекстов - это, ну, границы. Границы, которые отделяются от части приложения от другого путем введения четко определенного контракта (интерфейса).

Я обычно отношусь к БК, как Сервисы в SOA. Для меня это означает, что в идеале это физически отдельные приложения (ОС-процессы/веб-сайты IIS). Разумеется, также разделены двоичные разряды. Вся связь между БК идеально асинхронна. В реальном мире это вряд ли возможно, но, по крайней мере, я не разрешаю транзакции между БК, потому что они являются чистым злом.

Надеюсь, что это поможет.