Обзор от Александра
Part I: Strategic & Tactical Design
Детальный разбор стратегического и тактического дизайна из книги Влада Хононова.
Learning Domain-Driven Design (Изучаем DDD — предметно-ориентированное проектирование)
Авторы: Vlad Khononov
Издательство: O'Reilly Media, 2021
Объём: 342 страниц
Практический DDD от Влада Хононова: стратегический и тактический дизайн, микросервисы, EDA и Data Mesh.
Оригинал
ПереводСтруктура книги
Книга состоит из четырёх частей, каждая из которых раскрывает важный аспект DDD:
Часть I: Strategic Design
Business subdomains, ubiquitous language, bounded contexts, team collaboration patterns.
Часть II: Tactical Design
Реализация бизнес-логики, архитектурные паттерны, паттерны коммуникации.
Часть III: Applying DDD in Practice
Эвристики проектирования, эволюция решений, Event Storming, brownfield-проекты.
Часть IV: Relationships
Связь с микросервисами, event-driven architecture, data mesh.
Часть I: Strategic Design
Business Subdomains
Автор предлагает классификацию поддоменов, присущих каждой компании:
Core Subdomain
- Конкурентное преимущество
- Высокая сложность
- Требует лучших специалистов
Supporting Subdomain
- Поддерживает core
- Средняя сложность
- Можно аутсорсить
Generic Subdomain
- Общие решения
- Готовые продукты
- Не дифференцирует бизнес
Ubiquitous Language и Bounded Contexts
Ubiquitous Language — единый язык, используемый внутри bounded context для обмена знаниями между доменными экспертами и разработчиками.
Business subdomains — это нечто присущее самой компании, их нужно выяснить. А вот границы bounded contexts — на совести проектировщика.
Team Collaboration Patterns
Cooperation Patterns:
- Partnership — тесное сотрудничество команд
- Shared Kernel — общий код между контекстами
Customer-Supplier Patterns:
- Conformist — downstream принимает модель upstream
- Anti-Corruption Layer — защитный слой трансляции
- Open-Host Service — публичный API
Для анализа взаимоотношений контекстов используется Context Map.
Часть II: Tactical Design
Варианты реализации бизнес-логики
Transaction Script
Простейший подход: процедурный код, организованный по транзакциям.
Active Record
Объекты, которые знают о своём хранении и содержат бизнес-логику.
Domain Model
Богатая модель с инкапсулированной логикой, Aggregates, Entities, Value Objects.
Event-Sourced Domain Model
Состояние как последовательность событий, полная история изменений.
Архитектурные паттерны
Layered Architecture
Presentation → Business Logic → Data Access. Классический подход.
Ports & Adapters
Hexagonal / Clean Architecture. Инверсия зависимостей.
CQRS
Разделение моделей чтения и записи для разных требований.
Паттерны коммуникации между Bounded Contexts
Model Translation:
- Stateless Translation — трансляция без состояния
- Stateful Translation — с агрегацией данных
Aggregate Integration:
- Outbox Pattern — надёжная публикация событий
- Saga — оркестрация распределённых транзакций
- Process Manager — сложная координация процессов
Часть III: Применение DDD на практике
Tactical Design Decision Tree
Автор определяет эвристику как «rule of thumb: not guaranteed to be perfect, yet sufficient for one's immediate goals» и приводит дерево решений:
1. Определите тип Subdomain → Core / Supporting / Generic
2. Выберите реализацию бизнес-логики → Transaction Script / Active Record / Domain Model
3. Подберите архитектурный паттерн → Layered / Ports & Adapters / CQRS
4. Определите стратегию тестирования → Unit / Integration / E2E
Vectors of Change
Изменения в доменах:
- Core → Supporting (коммодитизация)
- Supporting → Core (новое преимущество)
- Generic → Supporting (специализация)
Организационные изменения:
- Partnership → Customer-Supplier
- Customer-Supplier → Separate Ways
- Слияния и разделения команд
Event Storming
Групповая техника моделирования для получения знаний о домене и формирования ubiquitous language:
Domain Events
Хронология
Триггеры + Actors
Автоматизация
Связанная книга
Building Microservices
Практическое руководство по построению микросервисов от Sam Newman — как применить DDD на практике.
Обзор от Александра
Part II: DDD and Microservices
Взаимосвязь Domain-Driven Design и микросервисной архитектуры.
Часть IV: DDD и Microservices
Что такое микросервис?
Влад говорит не о самом размере сервиса, а о размере его публичного интерфейса, который и должен быть «микро».
Deep Services ✅
- Узкий публичный интерфейс
- Сложная внутренняя логика
- Хорошая инкапсуляция
- Контролируемая глобальная сложность
Shallow Services ❌
- Широкий интерфейс
- Простая реализация
- Плохая инкапсуляция
- Рост глобальной сложности
Гранулярность vs Сложность
Чем меньше микросервисы → меньше локальная сложность каждого, но больше общая сложность системы из-за взаимодействий.
Цель хорошего дизайна — минимизировать общую сложность, а не размер отдельных сервисов.
Эвристики для границ микросервисов
Bounded Context
Каждый микросервис — bounded context, но не наоборот!
Aggregates
Нижняя граница «глубины» микросервиса.
Business Subdomains
Лучшая эвристика! Коррелируют с бизнес-возможностями.
Обзор от Александра
Part III: Event-Driven Architecture
Глубокий анализ событийно-ориентированной архитектуры в контексте DDD.
Event-Driven Architecture
EDA vs Event Sourcing
Event-Driven Architecture
- Архитектурный стиль
- Асинхронное взаимодействие
- Между компонентами системы
Event Sourcing
- Паттерн хранения данных
- Состояние как цепочка событий
- Внутри одного сервиса
Типы сообщений
Events vs Commands:
- Event — факт, который произошёл (прошедшее время)
- Command — запрос на действие (императив)
Типы Events:
- Event Notification — уведомление о факте
- Event-Carried State Transfer — с данными
- Domain Event — бизнес-событие
Типы Coupling в EDA
«Choosing the correct type of event message is what makes (decouples) or breaks (couples) a distributed system.»
Implementation Coupling
Зависимость от деталей реализации
Functional Coupling
Зависимость от бизнес-логики
Temporal Coupling
Зависимость от времени выполнения
Обзор от Александра
Part IV: Data Mesh
Разбор концепции Data Mesh и её связи с Domain-Driven Design.
Data Mesh
Analytical vs Transactional Data Model
Transactional (OLTP)
- Высокая гранулярность
- Предсказуемые запросы
- Нормализация данных
- Оптимизация для записи
Analytical (OLAP)
- Агрегированные данные
- Ad-hoc запросы
- Star / Snowflake schema
- Оптимизация для чтения
Проблемы DWH и Data Lake
- Centralised ownership → bottleneck
- Жёсткий coupling через ETL
- Одна модель на всю организацию
- Data swamp (болото данных)
- Потеря контекста
- Проблемы с качеством данных
Четыре принципа Data Mesh
1. Domain Ownership
Команды доменов владеют своими аналитическими данными.
2. Data as a Product
Данные — это продукт с SLA, документацией, версионированием.
3. Self-Serve Platform
Платформа для self-service публикации и потребления данных.
4. Federated Governance
Децентрализованное управление с общими стандартами.
Data Mesh отлично комбинируется с DDD: bounded contexts становятся data products, ubiquitous language определяет схему данных.
Применение на System Design Interview
Когда применять DDD:
- Определение границ сервисов через bounded contexts
- Выбор архитектуры на основе типа subdomain
- Проектирование интеграций (ACL, Open-Host)
- Event Storming для discovery фазы
Ключевые концепции:
- Deep Services — узкий интерфейс, богатая логика
- Aggregates — нижняя граница микросервиса
- Context Map — карта интеграций
- EDA patterns — для слабой связности