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
Процедурная логика вокруг конкретного бизнес-действия или транзакции.
Active Record
Объект совмещает данные, простые правила и знание о своём хранении.
Domain Model
Богатая модель с сущностями, значениями, агрегатами и инкапсулированными правилами.
Event-Sourced Domain Model
Состояние восстанавливается из истории событий, а не только из текущей записи.
Архитектурные паттерны
Layered Architecture
Классические слои: интерфейс, бизнес-логика и доступ к данным.
Ports & Adapters
Домен изолирован от внешних систем через порты и адаптеры.
CQRS
Команды и чтение разделяются, когда им нужны разные модели и требования.
Интеграция между ограниченными контекстами
Перевод моделей
- Перевод без состояния — каждый запрос переводится независимо
- Перевод с состоянием — адаптер хранит промежуточную модель или агрегирует данные
Интеграция агрегатов
- Outbox Pattern — событие публикуется надёжно вместе с изменением данных
- Saga — длинный процесс разбивается на шаги и компенсации
- Process Manager — отдельный компонент координирует сложный бизнес-процесс
Часть III: DDD на практике
Дерево решений для тактического дизайна
Эвристика в книге — это не идеальное правило, а достаточно хорошая подсказка для ближайшего решения.
1. Определите тип поддомена: ключевой, поддерживающий или типовой.
2. Выберите способ реализации бизнес-логики: от простого сценария до богатой доменной модели.
3. Подберите архитектурный стиль: слои, порты и адаптеры или разделение команд и чтения.
4. Согласуйте стратегию тестирования с ценой ошибки и скоростью изменений.
Векторы изменений
Изменения в домене
- Ключевой поддомен может стать типовой задачей, если рынок догоняет решение.
- Поддерживающая область может стать ключевой, если появляется новое преимущество.
- Готовый продукт может потребовать собственной модели, если бизнес сильно специализируется.
Изменения в организации
- Партнёрство команд может смениться отношением заказчик-поставщик.
- Команды могут разойтись по разным целям, темпу релизов и зонам ответственности.
- Слияния и разделения команд должны пересматривать границы контекстов.
Event Storming
Групповая техника помогает быстро собрать знания о домене, увидеть причинно-следственные связи и сформировать общий язык команды.
Найти доменные события и важные факты.
Разложить события по времени и причинности.
Понять, кто или что запускает действие.
Описать автоматические реакции на события.
Отметить зависимости за пределами домена.
Найти объекты, которые защищают бизнес-инварианты.
Сгруппировать модель по языку, правилам и ответственности.
Связанная книга
Building Microservices
Практический взгляд Sam Newman на то, как доменные границы превращаются в сервисы, контракты и эксплуатационную ответственность.
Обзор от Александра
DDD и микросервисы
Разбор связи между Domain-Driven Design, размером публичного интерфейса и реальными границами сервисов.
Часть IV: DDD и микросервисы
Что делает сервис микросервисом
В книге важен не абсолютный размер сервиса, а размер его публичного интерфейса. Хороший сервис может быть сложным внутри, если наружу он показывает небольшую и понятную поверхность.
Глубокий сервис
- Узкий публичный интерфейс
- Сложная внутренняя логика
- Хорошая инкапсуляция
- Контролируемая общая сложность
Поверхностный сервис
- Широкий интерфейс
- Простая реализация
- Плохая инкапсуляция
- Рост сложности всей системы
Гранулярность и сложность
Чем мельче сервисы, тем проще каждый из них по отдельности, но тем дороже становится сеть взаимодействий между ними.
Цель хорошей декомпозиции — снижать общую сложность системы, а не гнаться за минимальным размером сервиса.
Эвристики для границ микросервисов
Глубокий сервис
узкий публичный интерфейс и богатая внутренняя логика
Поверхностный сервис
широкий интерфейс, слабая инкапсуляция и рост общей сложности
Ограниченный контекст
каждый микросервис может быть контекстом, но не каждый контекст обязан стать сервисом
Агрегаты
нижняя граница, ниже которой сервис обычно становится слишком мелким
Бизнес-поддомены
хорошая эвристика для поиска устойчивых границ
Обзор от Александра
Событийно-ориентированная архитектура
Как разные типы событий помогают уменьшать связанность между контекстами и сервисами.
Событийно-ориентированная архитектура
Событийный стиль и Event Sourcing
Событийно-ориентированная архитектура
- Архитектурный стиль
- Асинхронное взаимодействие
- Связь между компонентами системы
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 с распределёнными компромиссами: транзакциями, согласованностью и границами ответственности.