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

Question

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

Я задаю этот вопрос по той причине, что информация из книг и других ресурсов слишком широка / абстрактна.

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

Кроме того, если вспомнить принципы ТВЕРДОГО и общую идею иметь небольшие слабо связанные частикод. Я предполагаю, что хорошо иметь максимум 3-4 агрегата на один ограниченный контекст. Если в одном ограниченном контексте больше агрегатов, то, вероятно, есть некоторые проблемы с дизайном программного обеспечения.

Я сейчас читаю книгу Вернона о DDD, но довольно сложно понять, как спроектировать, конечно, такиевещи.

Answer 1

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

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

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

Answer 2

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

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

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

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

См. Mauro Servienti: Все наши агрегаты неверны