Ограниченный контекст - это полное приложение?

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

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

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

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

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

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

Я, кажется, этот вопрос, где @MikeSW утверждает, что оба подхода, представленные OP, действительны. Я спрашиваю о третьей структуре:

<bc 1>
 |_ domain
 |_ infrastructure
<bc 2>
 |_ domain
 |_ infrastructure
|_ application
|_ presentation

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

Итак, ограниченный контекст - полное применение? Или можно использовать ограниченный контекст, как я понял, и чувствовал себя более полезным? Есть проблемы с моим подходом?

Ответ 1

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

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

Существует много правильных способов кодирования DDD. Вы должны спросить себя: "Я следую основному принципу, делая это так"

Ответ 2

Уровень домена обычно является самой сложной частью вашей программы и может также часто меняться из-за требований бизнеса и рефакторинга. Таким образом, вы, как правило, не хотите подвергать его прямому уровню презентации или другим ограниченным контекстам. Если вы чувствуете, что можете его разоблачить, может быть, что ваша прикладная логика или методы использования case смешаны с вашим доменным уровнем или что ваша программа невелика или сложна, чтобы начать с BC. В противном случае я бы включил уровень приложения в каждом BC для защиты целостности модели домена и выставлял только команды, которые нужно вызывать из перспективы использования.

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

У вас может быть тонкий прикладной уровень для каждого ограниченного контекста и все еще есть один уровень представления. Это иногда называют "составным UI", который сам по себе должен рассматриваться как отдельный BC. Если вам необходимо обрабатывать общую логику, такую как аутентификация, создать другую прикладную услугу или фасад в составном пользовательском интерфейсе и обработать ее аутентификацию, прежде чем, в свою очередь, вызвать службу приложения внешнего BC.

Я думаю, что большинство примеров, которые вы видите в книгах и в Интернете, чрезмерно упрощены, поскольку они имеют 1 BC на физическое запущенное приложение (и выполняют некоторую сетевую связь между ними), тогда как в реальном мире вы можете имеют сложное приложение, которое нужно разбить на отдельные логические единицы, но не запускать их как отдельные процессы, если только не придет необходимость.

Ответ 3

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

Что бы вы ни делали, чтобы предотвратить прямые ссылки в контекстах, прекрасно ли это означает, что это разные пространства имен, разные сборки внутри решения или разные проекты.

Ответ 4

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