DDD полезен не словарем терминов, а тем, что помогает увидеть границы модели до того, как систему начнут резать на сервисы.
Для реального проектирования глава показывает, как ограниченные контексты, единый язык модели и стратегический дизайн превращаются в основу API-границ, контрактов между командами и более честного распределения ответственности.
Для интервью и инженерных разборов она полезна тем, что помогает говорить об общей модели, смысловых расхождениях и случайной связанности между доменами без скатывания в абстрактную теорию.
Практическая польза главы
Практика проектирования
Используйте ограниченный контекст как основу для API-границ и контрактов между командами.
Качество решений
Формируйте единый язык модели, чтобы команды одинаково понимали правила предметной области.
Аргументация на интервью
Связывайте DDD-артефакты с практическими решениями: событиями, антикоррупционным слоем и владением моделью.
Анализ отказов
Контролируйте риски общей модели и случайной связанности между доменами.
Обзор от Александра
Стратегический и тактический дизайн
Разбор первой части книги: как DDD связывает бизнес-поддомены, язык модели и границы контекстов.
Learning Domain-Driven Design (Изучаем DDD — предметно-ориентированное проектирование)
Авторы: Vlad Khononov
Издательство: O'Reilly Media, 2021
Объём: 342 страниц
Практический DDD от Влада Хононова: ограниченные контексты, единый язык модели, тактические паттерны, микросервисы и подход Data Mesh.
Предметно-ориентированное проектирование (DDD) обычно тонет в словаре паттернов. В этой главе оно разбирается как способ договориться о модели до того, как начнётся спор о коде: найти , собрать и провести по тем линиям, где расходятся правила, ответственность и темп развития. Где эти линии размыты, граница позже прорастает сквозь код и стоит дорого.
Дальше книга связывает , и в одну практическую картину — это не четыре независимых набора терминов, а одно доменное мышление, доведённое до архитектуры.
Структура книги
Книга идёт от поиска доменных границ к архитектурным решениям, которые из этих границ вытекают: сначала понять домен, потом выбирать сервисы, события и данные — а не наоборот.
Часть I: стратегический дизайн
С чего начинать: бизнес-поддомены, единый язык предметной области, ограниченные контексты и то, как форма команд задаёт форму модели.
Часть II: тактический дизайн
Способы реализации бизнес-логики, архитектурные стили и интеграция между контекстами.
Часть III: DDD на практике
Эвристики проектирования, эволюция решений, моделирование Event Storming и работа с существующими системами.
Часть IV: связи с архитектурой
Куда это ведёт дальше: микросервисы, событийно-ориентированная архитектура и подход Data Mesh — продолжение доменного мышления, а не отдельные дисциплины.
Часть I: стратегический дизайн
Бизнес-поддомены
Влад Хононов начинает с простого вопроса: какие части бизнеса действительно уникальны, а какие можно реализовать проще или купить готовыми. От ответа зависит, куда уходит инженерное время.
Ключевой поддомен
Здесь живёт конкурентное преимущество — сюда и стоит вкладывать лучшие инженерные силы.
- Высокая сложность
- Нельзя купить готовым продуктом
- Имеет смысл развивать внутри
Поддерживающий поддомен
Бизнесу нужен, но рынок здесь ничем не выделить — переусложнять его значит тратить силы впустую.
- Средняя сложность
- Можно упростить
- Не всегда требует идеального дизайна
Типовой поддомен
Та же задача, что и у всех; писать своё дороже, чем взять готовое решение.
- Низкая уникальность
- Подходит коробочный продукт
- Не стоит превращать в ядро системы
Единый язык и ограниченные контексты
Единый язык держит доменных экспертов и разработчиков на одной модели и одних словах — без него одно и то же слово в разговоре и в коде начинает значить разное. Работает он только внутри одного ограниченного контекста, не шире.
Бизнес-поддомены в компании обычно уже есть, а вот границы контекстов проектирует команда. Здесь и решается, где одна модель заканчивается и начинается другая — провести границу не там значит платить за неё потом.
Паттерны взаимодействия команд
Сотрудничество
- Partnership — партнёрское взаимодействие: команды вместе развивают решение и синхронизируют модель
- Shared Kernel — общее ядро: небольшая общая часть модели поддерживается совместно
Заказчик и поставщик
- Conformist — подстройка под модель поставщика: нижестоящая команда принимает модель вышестоящей
- Anti-Corruption Layer — антикоррупционный слой защищает модель от чужих понятий
- Open-Host Service — открытый сервисный интерфейс задаёт правила интеграции
Эти отношения удобно разложить на карте контекстов. За связями систем она показывает форму зависимости между командами — а именно команды чаще всего и определяют, какая интеграция выживет.
Часть II: тактический дизайн
Варианты реализации бизнес-логики
Transaction Script
Транзакционный сценарий: процедурная логика вокруг конкретного бизнес-действия или транзакции.
Активная запись
Объект совмещает данные, простые правила и знание о своём хранении.
Domain Model
Доменная модель: богатая модель с сущностями, значениями, агрегатами и инкапсулированными правилами.
Event-Sourced Domain Model
Доменная модель на событиях: состояние восстанавливается из истории событий, а не только из текущей записи.
Архитектурные паттерны
Layered Architecture
Слоистая архитектура: классические слои интерфейса, бизнес-логики и доступа к данным.
Ports & Adapters
Архитектура портов и адаптеров: домен изолирован от внешних систем через порты и адаптеры.
CQRS
Разделение команд и чтения (CQRS), когда им нужны разные модели и требования.
Интеграция между ограниченными контекстами
Перевод моделей
- Перевод без состояния — каждый запрос переводится независимо
- Перевод с состоянием — адаптер хранит промежуточную модель или агрегирует данные
Интеграция агрегатов
- Паттерн исходящих событий (Outbox Pattern) — транзакционный журнал исходящих событий публикует событие надёжно вместе с изменением данных
- Saga — длинный процесс разбивается на шаги и компенсации
- Process Manager — менеджер процесса координирует сложный бизнес-процесс
Часть III: DDD на практике
Дерево решений для тактического дизайна
Эвристика в книге — это не идеальное правило, а достаточно хорошая подсказка для ближайшего решения.
1. Определите тип поддомена: ключевой, поддерживающий или типовой.
2. Выберите способ реализации бизнес-логики: от простого сценария до богатой доменной модели.
3. Подберите архитектурный стиль: слои, порты и адаптеры или разделение команд и чтения.
4. Согласуйте стратегию тестирования с ценой ошибки и скоростью изменений.
Векторы изменений
Изменения в домене
- Ключевой поддомен может стать типовой задачей, если рынок догоняет решение.
- Поддерживающая область может стать ключевой, если появляется новое преимущество.
- Готовый продукт может потребовать собственной модели, если бизнес сильно специализируется.
Изменения в организации
- Партнёрство команд может смениться отношением заказчик-поставщик.
- Команды могут разойтись по разным целям, темпу релизов и зонам ответственности.
- Слияния и разделения команд должны пересматривать границы контекстов.
Event Storming
Групповая сессия за пару часов вытаскивает знания о домене из голов, выстраивает причинно-следственные связи на стене и заодно проверяет, одинаково ли команда называет одни и те же вещи.
Неструктурированное исследование
Оранжевые доменные события
Команда сначала собирает факты, которые уже произошли в домене, без попытки сразу проектировать систему.
Хронология
События слева направо
Оранжевые события выстраиваются по времени и причинности, чтобы увидеть основной поток и пропуски.
Команды
Синие команды и жёлтые акторы
К событиям добавляют намерения и людей или системы, которые запускают действие.
Политики
Фиолетовые реакции
Автоматические правила связывают событие с новой командой и делают причинность явной.
Внешние системы
Розовые зависимости
Сторонние сервисы выделяются отдельно, чтобы команда видела границы контроля и интеграционные риски.
Представления
Зелёные read models
Команда отмечает, какие экраны, отчёты и модели чтения нужны людям для принятия решений.
Агрегаты
Желтые группы правил
Агрегаты собирают команды и события вокруг объектов, которые защищают бизнес-инварианты.
Ограниченные контексты
Пунктирные границы модели
В конце доску группируют по языку, правилам и ответственности, не притворяясь, что у контекста есть один канонический цвет.
Легенда цветов
Красный hotspot не является отдельным этапом: его добавляют в любой момент, когда появляется вопрос, риск или спорное правило.
Связанная книга
Building Microservices
Практический взгляд Sam Newman на то, как доменные границы превращаются в сервисы, контракты и эксплуатационную ответственность.
Обзор от Александра
DDD и микросервисы
Разбор связи между Domain-Driven Design, размером публичного интерфейса и реальными границами сервисов.
Часть IV: DDD и микросервисы
Что делает сервис микросервисом
«Микро» в книге — это про размер публичного интерфейса, а не про число строк внутри. Сервис может быть сложным внутри и оставаться хорошим, пока наружу торчит небольшая и понятная поверхность; именно по ней его и придётся поддерживать остальным командам.
Глубокий сервис
- Узкий публичный интерфейс
- Сложная внутренняя логика
- Хорошая инкапсуляция
- Контролируемая общая сложность
Поверхностный сервис
- Широкий интерфейс
- Простая реализация
- Плохая инкапсуляция
- Рост сложности всей системы
Гранулярность и сложность
Чем мельче сервисы, тем проще каждый по отдельности — но сложность не исчезает, а перетекает в сеть вызовов между ними, и платить за неё приходится задержками, отказами и отладкой.
Поэтому хорошая декомпозиция целится в общую сложность системы, а не в минимальный размер отдельного сервиса. Самый мелкий сервис почти никогда не самый дешёвый.
Эвристики для границ микросервисов
Глубокий сервис
узкий публичный интерфейс и богатая внутренняя логика
Поверхностный сервис
широкий интерфейс, слабая инкапсуляция и рост общей сложности
Ограниченный контекст
каждый микросервис может быть контекстом, но не каждый контекст обязан стать сервисом
Агрегаты
нижняя граница, ниже которой сервис обычно становится слишком мелким
Бизнес-поддомены
хорошая эвристика для поиска устойчивых границ
Обзор от Александра
Событийно-ориентированная архитектура
Как разные типы событий помогают уменьшать связанность между контекстами и сервисами.
Событийно-ориентированная архитектура
Событийный стиль и хранение состояния через события
Событийно-ориентированная архитектура
- Архитектурный стиль
- Асинхронное взаимодействие
- Связь между компонентами системы
Хранение состояния через события (Event Sourcing)
- Паттерн хранения состояния
- История изменений как цепочка событий
- Обычно применяется внутри одного сервиса или агрегата
Типы сообщений
Событие
факт, который уже произошёл и сформулирован в прошедшем времени
Команда
запрос на действие, сформулированный как намерение
Уведомление о событии
минимальный сигнал о факте без лишнего состояния
Событие с переносом состояния
сообщение содержит данные, нужные потребителю
Доменное событие
бизнес-факт, важный внутри предметной области
Типы связанности в событийной архитектуре
Тип события — это решение о связанности. Один выбор развязывает сервисы, другой незаметно стягивает их ещё сильнее, и обнаруживается это обычно уже на проде.
Связанность реализации
потребитель зависит от внутренних деталей поставщика
Функциональная связанность
сервисы слишком тесно завязаны на один бизнес-процесс
Временная связанность
стороны должны быть доступны одновременно или в жёстком порядке
Обзор от Александра
Подход Data Mesh и DDD
Как доменные границы и единый язык помогают строить дата-продукты и федеративное управление.
Подход Data Mesh и DDD
Аналитическая и транзакционная модели данных
Транзакционная обработка (OLTP)
- Детальные записи
- Предсказуемые запросы
- Нормализованные данные
- Оптимизация под запись
Аналитическая обработка (OLAP)
- Агрегированные данные
- Исследовательские запросы
- Звезда или снежинка
- Оптимизация под чтение
Проблемы централизованных DWH и озёр данных
- Центральная команда становится узким местом.
- Жёсткая связанность через процессы извлечения, преобразования и загрузки (ETL) усложняет изменения.
- Одна модель плохо описывает разные доменные контексты.
- Озеро данных превращается в болото без владельцев и контекста.
- Потребители теряют смысл полей и правила качества.
- Исправление ошибок отрывается от команды-источника.
Четыре принципа подхода Data Mesh
Доменная ответственность
команды доменов отвечают за свои аналитические данные
Данные как продукт
у данных есть потребители, документация, метрики качества и соглашение об уровне сервиса (SLA)
Платформа самообслуживания
публикация и потребление данных не требуют ручной очереди в центральную команду
Федеративное управление
общие стандарты сочетаются с локальной ответственностью доменов
Подход Data Mesh ложится на DDD почти без зазора: ограниченные контексты становятся основой дата-продуктов, а единый язык предметной области задаёт и схему, и смысл данных — а не только имена колонок.
Применение на интервью по системному дизайну
Когда применять DDD
- Определять границы сервисов через ограниченные контексты.
- Выбирать архитектуру по типу поддомена и цене ошибки.
- Проектировать интеграции через карту контекстов и антикоррупционный слой.
- Использовать моделирование Event Storming на этапе исследования предметной области.
Ключевые концепции
- Глубокие сервисы — узкий интерфейс и сильная внутренняя модель
- Агрегаты — минимальная граница согласованного изменения
- Карта контекстов — схема отношений и интеграций между моделями
- Событийные паттерны — инструменты для слабой связанности между контекстами
Дополнительные материалы
Связанные главы
- Зачем нужны микросервисы и интеграция - Общий контекст раздела: где DDD помогает не потерять границы сервисов, контрактов и ответственности.
- Стратегии декомпозиции - Практика выбора границ через ограниченные контексты, бизнес-возможности и устройство команд.
- Building Microservices (short summary) - Как идеи DDD переходят в эксплуатацию сервисов, владение контрактами и эволюцию микросервисной архитектуры.
- Introducing Domain-Oriented Microservice Architecture - Кейс Uber о том, как доменно-ориентированный подход связывает архитектуру, платформу и организационный рост.
- Data Mesh in Action (подход Data Mesh в действии) - Как доменная ответственность и продуктовый подход к данным продолжают DDD-логику в крупных организациях.
- Software Architecture: The Hard Parts (краткий обзор) - Связь DDD с распределёнными компромиссами: транзакциями, согласованностью и границами ответственности.