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

После месяца или около того чтения и исследования DDD я решил начать свой собственный проект и создал DDD с этими ограниченными контекстами>

• клиенты
• Товары
• заказы
• Billing

Каждый ограниченный контекст имеет API покоя в качестве уровня представления, уровня домена, постоянного уровня.

Пока все хорошо, код работает гладко, но, исходя из монолитного мира, я все еще пытаюсь выяснить следующее:

• когда я хочу создать нового клиента, выставить новый счет, создать новый заказ, например, список доступа стран. Должен ли я:

а) создать список стран в каждом БК

б) создать Страны БК -> API и использовать его для получения списка доступных стран

c) использовать сторонний API и извлекать данные через антикоррупционный слой в каждом BC

• при интеграции со сторонним API с использованием антикоррупционного уровня или уровня адаптера, какие данные должны быть включены в мою модель домена? Например, если я хочу интегрировать API zendesk с клиентом BC. Нужен ли мне просто ticketID в моем домене или я должен извлечь все данные из Zendesk, к которым я хочу получить доступ и использовать в Client BC?

Если мое приложение MVC на самом деле получает данные из API (уровни представления моего ограниченного контекста), мне очень трудно четко определить границы каждого BC. Означает ли это, что правильно спроектированный BC будет обслуживать один контроллер MVC без необходимости использования дополнительных API?

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

Я также хотел немного взглянуть на вашу модель. Части, которые вы перечислили, вполне могут быть «сущностями» в одном «ограниченном контексте», в зависимости от структуры компании. БК часто заканчиваются в разных областях / отделах / командах, поскольку это часто естественная граница между «вездесущими языками». Так, например, вместо продаж / продуктов / заказов я бы ожидал, что БК будут такими же, как продажи / производство / складирование.

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

... все модели ошибочны, но некоторые полезны.

Также имейте в виду, что каждый BC может использовать совершенно другую систему или архитектуру. Данный BC может вообще не заслуживать использования «программных компонентов DDD», и большинство из них, вероятно, этого не делают. DDD - это не столько предписывающие программные компоненты, сколько процесс разработки программного обеспечения. Задача состоит в том, чтобы сосредоточиться на понимании ограниченных контекстов компании, намечении повсеместных языков каждого контекста и моделировании кода для этого контекста с использованием их повсеместного языка. Таким образом, когда вы взаимодействуете с заинтересованными сторонами и обращаетесь к коду, для них это звучит так, будто вы говорите в деловых терминах, которые они понимают. И признавая, что одно и то же слово имеет разные значения в разных БК.

Существуют определенные шаблоны, созданные DDD (например, хранилище, определенные слои и т. Д.), Которые являются средством для достижения цели. Но эти шаблоны не гарантируют, что они будут лучшими для каждого случая, даже в рамках DDD. Так же, как DDD не является "ответом" на каждый проект. Вам просто нужно сделать то, что предлагает ваш анализ, это наиболее практичная вещь.

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

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

Например, в клиентском домене «страна» может быть связана с местом жительства или гражданством. В биллинге это может быть связано с курсами обмена валют. В некоторых из этих доменов вам может понадобиться беспокоиться о тарифах и тому подобном.

Второй вопрос, который вам нужно задать, - это какая из ваших моделей является книгой рекордов для «общих» данных. В случае «страны» правильный ответ, вероятно, таков, что ни один из них не является! Геополитическая топология не контролируется вашей моделью.

Что должно происходить в ваших моделях доменов, когда страна оккупирована иностранной державой?

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

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

Мое мнение на эту тему - определить ограниченный контекст, используя отображение бизнес-возможностей или другие подобные методы, такие как анализ цепочки создания стоимости. Это сводится к следующим шагам:

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

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

Пара практических советов:

1. Если одному из ваших контекстов / сервисов / и т.д. нужны данные другого контекста, скорее всего, ваши границы неверны.
2. Весьма желательный способ контекстной коммуникации основан на событиях. Это ключ к масштабируемости и надежности. Если вам нужно синхронное общение, скорее всего, опять же, вы не правы. Кроме того, синхронная связь убьет вашу систему.
3. Ваш домен более последовательный, чем вы думаете. Так же, как и все остальные. Не пытайтесь сделать все на 100% последовательным. В этом нет практического смысла.
4. Контексты не должны быть организованы. Они автономны. Как люди.

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