DDD простым языком
Понятия
- Доменный эксперт - человек отлично знающий все бизнес процессы.
- Ubiquitos language - единый язык для общения разработчика с доменным экспертом (UML и понятно написанный код).
- Bounded context - ограниченный контекст (некий один достаточно большой бизнес процесс, роль или обязанность).
В DDD, область применения доменной модели называется изолированным контекстом (Bounded context). Изолированный контекст включает в себя код, который реализует модель.
При использовании микросервисной архитектуры изолированный контекст соответствует одному или нескольким сервисам.
| Структура и иерархия | Описание |
| Компания | Пример: например Амазон |
| - domain | Пример: интернет магазин Амазон |
| - domain | Пример: облачные вычисления Амазон |
| - - subdomain | Достаточно масштабная бизнес-обязанность (bounded context), например: бухгалтерия, доставка и т.п. Например для бухгалтерии мы используем "1С Бухгалтерия" в рамках которого есть единый Ubiquitous language. |
| - - - core | Основные вещи (то, без чего subdomain не имеет смысла), то, без чего субдомен не состоится |
| - - - supporting | Второстепенные внутренние вещи, например: формирование заказа, маркетинг |
| - - - generic | Второстепенные внешние вещи - то, что может быть отдано на аутсорс, например оплата через Paypal |
| - - - - aggregate | Агрегат - некая бизнес-сущность, которая состоит из других бизнес-объектов |
| - - - - - entity | Сущность — бизнес объект имеющий уникальный ID/GUID, содержит небольшой набор критических бизнес-правил, оперирующих критическими бизнес-данными. Объект-сущность или содержит критические бизнес-правила в себе, или имеет простой доступ к ним (например: банк взимает XX% за кредит). Интерфейс сущности состоит из функций, реализующих критические бизнес-правила и оперирующих этими данными. Критические правила и критические данные неразрывно связаны друг с другом, поэтому являются отличными кандидатами на объединение в объект (название предложил Ивар Якобсон). |
| - - - - - - value object | Объект значение - бизнес объект не имеющий уникального идентификатора. Два объекта value с одинаковыми значениями атрибутов считаются равными. |
Варианты использования
Определяют, как и когда вызываются критические бизнес-правила в сущности. Варианты использования управляют действиями сущности (например: Банк может решить, что сотрудники, оформляющие кредиты, не должны предлагать график погашения кредита, пока не соберут и не проверят контактную информацию и не убедятся, что кандидат имеет кредитный балл 500).
Бизнес-правила
Бизнес-правила являются причиной существования программной системы. Они составляют основу функционирования. Они порождают код, который делает или экономит деньги. Они — наши семейные реликвии. Бизнес-правила должны оставаться в неприкосновенности, незапятнанными низкоуровневыми аспектами, такими как пользовательский интерфейс или база данных. В идеале код, представляющий бизнес-правила, должен быть сердцем системы, а другие задачи — просто подключаться к ним. Реализация бизнес-правил должна быть самым независимым кодом в системе, готовым к многократному использованию.
Поддомены VS сервисы
Рассмотрим пример домена компании FTGO:
В книге Domain Driven Design, Eric Evans создает классификацию различных типов объектов предметной области, и давайте посмотрим про отличие анемичной доменной модели от модели агрегата:
Мартин Фаулер говорит так: логика домена (domain logic) имеет дело только с предметной областью как таковой (примером могут служить стратегии вычисления зачтенного дохода по контракту), а логика приложения (application logic) описывает сферу ответственности приложения (скажем, уведомляет пользователей и сторонние приложения о протекании процесса вычисления доходов).
Альтернативой является — table driven design (Active record, которая отражает суть предметной области).
Тактические паттерны
При реализации любого из видов моделей часто используют паттерны:
- separated interface - интерфейс модели, который должен быть в доменном слое, а реализация в инфраструктурном слое (чтобы избавить доменную логику от сторонних зависимостей).
- отложенные эвенты - события которые срабатывают, когда транзакция закомичена, но не раньше.