Структура одного ограниченного контекста

Связан ли ограниченный контекст по всем уровням приложений (домен, приложение, презентация и инфраструктура) или только модель домена? Например, я должен использовать следующую структуру:

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

или следующее:

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

Ответ 1

Оба являются действительными подходами. Я предпочитаю первый вариант, потому что он обеспечивает лучшую модульность и четкие границы для высокого уровня ВС. Второй вариант - это "стандартный" способ сделать это, и это позволяет говорить о более техническом наслаивании, в то время как первый вариант в буквальном смысле способствует более упорядоченному домену.

Выберите тот, с которым вам будет комфортно.

Ответ 2

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

Если вы хотите получить более точный ответ, добавьте материал на свой вопрос, чтобы мы могли получить ваш контекст и вашу проблему.

Ответ 3

Я думаю, что речь идет не о DDD точно, а о архитектуре. Какая связь между ограниченным контекстом приемлема/желательна для вас.

Если все ваши ограниченные контексты будут:

будет разработан на одном языке программирования
Доступ к тому же движку базы данных
разрабатывается относительно небольшой командой (до ~ 20 человек).

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

В других случаях вам следует учитывать архитектуру микросервисов/SOA.