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

Question

Я имею в виду - физически, в коде. Организация именования, пространства имен, папки, сборки, база данных/с.

Насколько ограниченные контексты должны взаимодействовать?

Например, не стесняйтесь использовать классический Бизнес-домен электронной коммерции.

Answer 1

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

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

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

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

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

Каждый из этих BC знал о «продуктах», но все они имели свой вид на продукт.

Например, покупка может иметь предприятие продукта с информацией о поставщике, прикрепленной к нему цены на покупку и т. Д.

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

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

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

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

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

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

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

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

Answer 2

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

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

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