Domain Driven Design DDD
Зачем
- Снизить сложность, избежать “большого комка грязи”
- Бизнес ценность достичь
- Модель предметной области (сущности-функции) - доменная модель
- Единый язык ИТ и бизнеса
- Код должен в себе отражать предметную область, т.е. классы должны соответствовать объектам реальной предметной области как по структуре, так и по поведению.
- Уменьшить зависимости
- разрыв зависимостей (связности) на уровне предметной области, а именно:
- устранение множественных, несовместимых на уровне моделей/контекстов, ответственностей и атрибутов
- Несовместимых здесь означает, что есть одна сущность, например Contract, используется в двух моделях и в каждой из моделей у этой сущности есть атрибуты или поведение, которые
- не определены в этой модели
- или имеют собственное определение в каждой из моделей. Каждая модель использует атрибут по-своему в своем контексте и изменения в одной модели могут привести (и часто приводят) к некорректному поведению в другой модели.
- Несовместимых здесь означает, что есть одна сущность, например Contract, используется в двух моделях и в каждой из моделей у этой сущности есть атрибуты или поведение, которые
- устранение множественных, несовместимых на уровне моделей/контекстов, ответственностей и атрибутов
- Несколько моделей Order не нарушают принципа DRY: не должны повторяться именно в поведении, а не в данных
- Причины изменений - люди. Люди, запрашивающие изменения. И вам бы не хотелось сбивать с толку людей и себя смешивая в одном месте код, нужный разным людям по разным причинам (Robert C. Martin (Uncle Bob))
- разрыв зависимостей (связности) на уровне предметной области, а именно:
- За счет автономности сервисов\модулей значительно упрощается управление техническим долгом
План самостоятельного обучения DDD, CQRS, EventSourcing.
Плюсы и минусы
Плюсы:
- Единый язык
Минусы:
- DDD на 90% проектов оверхед, который не стоит потраченных усилий? Но это не повод не учиться.
Паттерны
Стратегическое проектирование
- Контекст
- Предметная область(проблема) Domain
- Делится на Подобласть
- делится по преимуществам для бизнеса
- 1 core ядро бизнеса - смысловое ядро - успех бизнеса
- 2 support поддерживающие ядро, жизненно необходимы
- 3 generic не критичная функциональность
- делится по преимуществам для бизнеса
- Пространство задач - бизнес целей, бизнес проблем. Подобласть Subdomain=Задачи бизнеса
- Пространство технических решений - ограниченных контекстов Bounded context = решение по Подобласти subdomain (не всегд 1-1)
- это явная граница, внутри которой существует модель предметной области, которая отображает ЕДИНЫЙ ЯЗЫК в модель программного обеспечения.
- Не всегда равно сервису, может применяться и в модульном монолите (например отдельные таблицы сущностей разных контекстов).
- Теоретически каждая подобласть может иметь несколько ограниченных контекстов, хотя мы стремимся, чтобы для одной подобласти он был один.
- Как искать границы Bounded context
- Данные
- Оргструктура
- Этапы бизнес процесса
- Роли - Заинтересованные лица
- Единый язык
- Свои цели и своя ответственность
- Карта ограниченных контекстов - интеграции между контекстами
Тактическое проектирование
Тактическое проектирование состоит из:
- Доменная модель
- Консистентность данных обеспечить
- Переход от анемичной к богатой модели
- Не допускать анемии модели
- Модель отображает связи
- В модели есть геттеры и сеттеры для свойств
- Модель описывает действия и логику домена
- При использовании универсальных анемичных моделей и слоя сервисов часто получаем широкое использование доменных классов внутри Сервисов. Что в свою очередь приводит к повышению связности Coupling.
- Изоляция от внешних зависимостей - слабая связность Coupling
- Агрегат Aggregate
- Состоит из
- Сущность Entity
- Описывает индивидуально существующие Элементы домена
- Определяется по идентификатору, а не по значению атрибутов
- Непрерывно и однозначно определяется на всём протяжении существования
- Объект значений Value Object
- Не обладает идентификатором
- Описывает элементы домена, полностью определяемые свойствами
- Неизменяемый после создания
- Используется для типизации и структурирования данных
- Сущность Entity
- Состоит из
- Шаблон Спецификация для бизнес правил
- Domain event Доменные события
- Слои приложения
- DDD трилема
- Clean Architecture
Агрегат (Aggregate root)
Агрегат - кластер из сущностей и объектов значений
- Определяется по идентификатору
- имеет глобальную идентичность, а остальные объекты локальную идентичность
- Является границей транзакции при изменении данных
- корень проверяет и гарантирует, что удовлетворяются все инварианты
- в случае изменения объекта все инварианты по-прежнему должны удовлетворяться
- Другие элементы домена не могут ссылаться на внутренности агрегата
- сущности, находящиеся вне агрегата, содержат ссылки только на корень
- Позволяет получить Low Coupling и Strong Cohesion
- вся бизнес-логика обычно локализована в самом агрегате, так мы получаем Strong Cohesion.
- при удалении агрегата удаляется вся содержавшаяся в нем информация
Слои приложения
- Служба Aplication Services
- Реализация Use Case UI
- Используют Domain Services
- CQRS - command, query and handler, command bus
- Служба Domain Services Interfaces
- Сервисы предоставляют приложению интерфейсы для работы с доменом
- Содержат методы, описывающие операции Домена
- Не содержат состояния
- Могут обращаться к репозиториям и другим сервисам
- Уносят логику из контроллеров
- Инфраструктурный слой
- Содержит реализации репозиториев и сервисов
- Знает о БД
- Работает с IOC контейнером
- Слой, предохраняющий абстракцию Anti Corruption Layer (ACL)
- Модули
Технологии
- Framework, Platform
- Plantuml + vs code
- Context Mapping DSL (CML) - A Modeling Framework for Strategic Domain-driven Design
- Microservice DSL (MDSL) support Generators. In the MDSL Editor, you can invoke the following generators from the “MDSL” entry in the context menu:
- Generate OpenAPI Specification
- Generate Protocol Buffers Specification
- Generate GraphQL Schema
- Generate Jolie Lang(uage) Specification
- Generate Java “Modulith” Code
- Generate ALPS specification (status: technology preview)
- Generate AsyncMDSL specification (this actually is an in-model transformation, it does not generate a new output file)
- Generate Text File with Freemarker Template
- Generate AsyncAPI (from AsyncMDSL). See page AsyncAPI Specification Generator and readme in this examples folder for further information.
- Generate MSML
- From MSML OpenAPI