Недавно я решил изучить проект, управляемый доменом. Я придумал гипотетическое приложение и попытался разработать для него архитектуру. Это простое приложение Poing-of-Sale с ограниченным контекстом Sales and Inventory. Именно здесь у меня есть два противоречивых проекта при реализации кода для этих ограниченных контекстов.Внедрение ограниченного контекста в доменном дизайне
Дизайн # 1:
Все и все, что имеет отношение к инвентарю относится в контексте инвентаризации ограничено.
Если приходит заказ на продажу, запрос первоначально входит в ограниченный контекст продаж, затем один из шагов для продажи, вы должны проверить инвентарь, чтобы узнать, доступен ли этот товар. В этом случае вы запрашиваете контекст инвентаризации (однако это делается в рамках системы). Контекст инвентаря будет проверять базу данных и отвечать на нее с подтверждением доступности. Таким образом, любые другие ограниченные контексты, которые требуют какой-либо инвентаризации, включали логику, использовали бы этот ограниченный контекст для ее достижения. Код инкапсулирован и хорош.
Дизайн # 2:
Разделение ограниченных контекстов строго по разделам уровня бизнеса в своих оперативных контекстах.
Если заказ на продажу приходит и попадает в ограниченный контекст продаж, он должен содержать всю логику кода, которая связана с продажами. Он проверил бы базу данных о том, доступен ли ресурс через службу, затем он удалит этот элемент из инвентаря, снова зарегистрирует продажи в базе данных через службу, отправит администратору уведомление об отправлении по электронной почте, если это необходимо. Просто все и все, что связано с продажами, будут происходить в этом ограниченном контексте. После того, как будет произведена продажа, он может запустить продажу события, а контекст инвентаря будет прослушивать это, чтобы проверить инвентарь в базе данных, посмотреть, нужно ли делать новые покупки для внесения нового инвентаря или нет, поскольку это связано с операцией к запасам на уровне бизнеса.
Я просто пытаюсь понять, какой подход под управлением домена Driven разработан в такой системе. Благодарю.
=================================
Подумав это добавленный вопрос оригинал.
Предположим, что ваш бизнес должен выполнять доставку. Будет ли это связано с продажей (ограниченным контентом) или из-за замены гарантии (ограниченный контекст поддержки). Что делать, если доставка сама по себе сложна в зависимости от ситуации. В тех случаях, когда определенные продукты или адреса доставки вам необходимо принять решение о доставке его самостоятельно или через какую-либо стороннюю судоходную компанию, используя веб-службу. «Судоходство» заслуживает собственного ограничения на доставку? Или это просто еще одна логика домена, встроенная в контекст ограниченных продаж и контекст, ограниченный поддержкой? Все это происходит в случае простого домена розничного магазина.
Возможный дубликат [Связь между двумя ограниченными контекстами в DDD] (http://stackoverflow.com/questions/16713041/communicating-between-two-bounded-contexts-in-ddd) – guillaume31
Я не думаю, что это дублируя, потому что я не просто интересуюсь референтными данными. В случае моего вопроса о доставке я пытаюсь определить, в какой момент имеет смысл иметь доставку как отдельный контекст. Или даже имеет смысл иметь отдельный контекст вообще? Как бизнес, что именно вы делаете, просто «отправляя», что он становится «ограниченным» контекстом? – jiminssy
Ограниченный контекст связан с концепцией субдомена. У вас есть субдомен, когда у вашей организации есть отдельные бизнес-процессы и часто выделенная команда для соответствующей функциональной области. См. Http://gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/ http://www.jefclaes.be/2014/02 /strategic-ddd-in-nutshell.html – guillaume31