Domain-Driven Design по фэншую

Памятка для раскраивания предметной области на примере учетной системы.

Возьмем небольшой кусочек интернет-магазина и попилим его по канону DDD.

Что есть домен? Домен – это сегмент предметной области, состоящий из связанных смыслом бизнес-сущностей и понятий. У домена всегда есть центральная сущность, вокруг которой строится предметно-инструментальная обвязка. Примеры:

Определите все бизнес-сущности, входящие в границу домена. Не включайте в список компоненты системной оснастки (уведомления, конфигурирование, контроль, безопасность, платформа для оркестровки и т.д.) – это особые универсальные сервисы за пределами парадигмы DDD.

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

Для каждого домена проектируем модель данных. Все модели должны быть строго изолированы и локализованы.

Простые архитекторы могут поместить всю модель домена в одну БД и жить счастливо. Иным, кто свято чтит канон и повторяет по утрам догмы микросервисов как мантры, позволено всё, можно разбивать модель по сущностям и даже больше. Да, будет больно, дорого и долго, но иначе совсем неспортивно.

Далее создаем аспектную модель под каждую бизнес-сущность.

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

Для каждой бизнес-сущности создайте свой набор API. Все интерфейсы должны быть заточены под сценарии управления данными.

Если вы затрудняетесь с разделением в каком-либо слое, то ориентируйтесь на здравый смысл. Вот несколько причин для разделения: