DDD: как разделить приложение на ограниченные контексты, помимо примера электронной коммерции?

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

На данный момент проблема номер один связана с ограниченным контекстом и контекстными картами. Может быть, я просто не понимаю, но мне кажется, что делать дивизию невозможно. Например, у нас есть объект User по всему месту, и он точно такой же объект пользователя: отображаемое имя, идентификатор и роли. Существует еще один пример: у нас есть объект CatalogItem, который помогает нам классифицировать другие объекты по всему месту. Должны ли мы вводить ограниченные контекстные зависимости? Есть ли какие-либо рекомендации по этому вопросу помимо этого утомительного примера электронной торговли?

Ответ 1

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

В примере, который вы даете, есть несколько вариантов:

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

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