Изучаем DDD – предметно-ориентированное проектирование

Предисловие редакторской группы
Предисловие
Введение
Зачем я написал эту книгу
Кому следует прочитать эту книгу
Навигация по книге
Пример предметной области: WolfDesk
Соглашения, используемые в этой книге
Порядок использования примеров кода
Благодарности
Вступление
ЧАСТЬ I. СТРАТЕГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ
ГЛАВА 1. Анализ предметной области
Так что же такое предметная область?
Что такое поддомен (subdomain)?
Типы поддоменов
Основные поддомены (core subdomains)
Универсальные поддомены (generic subdomains)
Вспомогательные поддомены (supporting subdomains)
Сравнение поддоменов
Конкурентное преимущество
Сложность
Изменчивость
Стратегия решения (solution)
Определение границ поддоменов
Выделение поддоменов (Distilling subdomains)
Поддомены с позиции согласующихся сценариев использования
Сосредоточьтесь на главном
Примеры анализа предметной области
Gigmaster
Предметная область (домен) и поддомены
Архитектурные решения
BusVNext
Предметная область (домен) и поддомены
Архитектурные решения
Кто такие специалисты в предметной области?
Выводы
Упражнения
ГЛАВА 2. Экспертные знания о предметной области
Задачи бизнеса (business problems)
Выявление экспертных знаний
Общение
Что такое единый язык?
Язык бизнеса
Сценарии
Согласованность
Неоднозначные понятия
Понятия-синонимы
Модель предметной области
Что такое модель?
Эффективное моделирование
Моделирование предметной области
Непрерывная работа
Инструменты
Сложности
Вывод
Упражнения
ГЛАВА 3. Как осмыслить сложность предметной области
Противоречивые модели
Что такое ограниченный контекст?
Границы модели
Уточнение термина «единый язык»
Область применения ограниченного контекста
Сравнение ограниченных контекстов и поддоменов
Поддомены
Ограниченные контексты
Взаимодействие поддоменов и ограниченных контекстов
Границы
Физические границы
Границы владения
Ограниченные контексты в реальной жизни
Семантические области
Наука
Покупка холодильника
Вывод
Упражнения
ГЛАВА 4. Интеграция ограниченных контекстов
Сотрудничество (Cooperation)
Партнерство (Partnership)
Общее ядро (shared kernel)
Общие рамки (Shared scope)
Реализация
Когда следует воспользоваться общим ядром
Потребитель-Поставщик (Customer-supplier)
Конформист (Conformist)
Предохранительный слой (Anticorruption layer)
Сервис с открытым протоколом (Open-Host Service)
Разные пути (Separate Ways)
Проблемы общения
Универсальный поддомен (Generic Subdomain)
Различия в моделях
Карта контекстов (Context Map)
Поддержка в актуальном состоянии
Ограничения
Вывод
Упражнения
ЧАСТЬ II. Тактический замысел
ГЛАВА 5. Реализация простой бизнес-логики
Транзакционный сценарий
Реализация
Это не так-то просто!
Отсутствие транзакционного поведения
Распределенные транзакции
Неявные распределенные транзакции
Когда следует применять транзакционный сценарий
Активная запись
Реализация
Когда следует применять активную запись
Придерживайтесь прагматичного подхода
Вывод
Упражнения
ГЛАВА 6. Проработка сложной бизнес-логики
Предыстория
Модель предметной области (доменная модель)
Реализация
Сложность
Единый язык
Строительные блоки
Объект-значение
Сущности
Агрегаты
Доменные сервисы (domain service)
Управление сложностью
Вывод
Упражнения
ГЛАВА 7. Моделирование фактора времени
События как источник данных (Event Sourcing)
Поиск
Анализ
Источник истины
Хранилище событий
Модель предметной области, основанная на событиях
Преимущества
Недостатки
Часто задаваемые вопросы
Производительность
Удаление данных
А почему просто нельзя ...
Вывод
Упражнения
ГЛАВА 8. Архитектурные паттерны
Сопоставление бизнес-логики и архитектурных паттернов
Слоистая архитектура (Layered Architecture)
Слой представления (Presentation layer)
Слой бизнес-логики (Business logic layer)
Слой доступа к данным (Data access layer)
Связь между слоями
Вариация
Сервисный слой (Service layer)
Терминология
Когда предпочтительнее использовать слоистую архитектуру
Дополнительно: сравнение слоев и уровней
Порты и адаптеры (Ports and adapters)
Терминология
Принцип инверсии зависимостей (Dependency inversion principle)
Интеграция инфраструктурных компонентов
Варианты
Когда предпочтительнее использовать порты и адаптеры
Разделение ответственности команд и запросов (Command-Query Responsibility Segregation)
Мультипарадигменное моделирование (Polyglot modelling)
Реализация
Модель выполнения команд
Модели чтения (проекции)
Проецирование моделей чтения
Синхронные проекции
Асинхронные проекции
Сложности
Разделение моделей
Когда предпочтительнее использовать CQRS
Область применения
Вывод
Упражнения
ГЛАВА 9. Паттерны взаимодействия
Преобразование моделей
Преобразование моделей без сохранения состояния
Синхронный режим
Асинхронный режим
Преобразование моделей с отслеживанием состояния
Агрегирование входящих данных
Объединение нескольких источников
Интеграция агрегатов
Паттерн исходящих сообщений (Outbox)
Извлечение неопубликованных событий
Сага
Согласованность
Диспетчер процессов
Вывод
Упражнения
ЧАСТЬ III. Применение предметно-ориентированного проектирования на практике
ГЛАВА 10. Эвристика проектирования
Эвристика
Ограниченные контексты
Паттерны реализации бизнес-логики
Архитектурные паттерны
Стратегия тестирования
Пирамида тестирования
Ромб тестирования
Перевернутая пирамида тестирования
Дерево тактических проектных решений
Вывод
Упражнения
ГЛАВА 11. Эволюция проектных решений
Изменения в предметных областях
Из основного в универсальный
Из универсального в основной
Из вспомогательного в универсальный
Из вспомогательного в основной
Из основного во вспомогательный
Из универсального во вспомогательный
Стратегические аспекты проектирования
Тактические аспекты проектирования
Преобразование транзакционного сценария в активную запись
Преобразование активной записи в модель предметной области
Преобразование модели предметной области в модель предметной области, основанную на событиях
Генерация прошлых переходов состояния
Моделирование событий миграции
Организационные изменения
Переход от партнерства к отношениям потребитель-поставщик
Переход от отношений потребитель-поставщик к модели разных путей
Знания предметной области
Рост проекта
Поддомены
Ограниченные контексты
Агрегаты
Вывод
Упражнения
ГЛАВА 12. EventStorming
Что такое EventStorming?
Кто принимает участие в EventStorming?
Что нужно для проведения EventStormin
Процесс проведения EventStorming
Этап 1: Проведение неструктурированного исследования
Этап 2: Выстраивание в хронологическом порядке
Этап 3: Проблемные места (pain points)
Этап 4: Выявление ключевых событий (pivotal events)
Этап 5: Выявление команд (commands)
Этап 6: Выявление правил (policies)
Этап 7: Выявление моделей чтения (read model)
Этап 8: Выявление внешних систем (external systems)
Этап 9: Выявление агрегатов
Этап 10: Выявление ограниченных контекстов
Варианты
Когда следует проводить EventStorming
Советы по проведению
Отслеживание динамики проведения семинара
Проведение EventStorming с удаленными участниками
Вывод
Упражнения
ГЛАВА 13. Предметно-ориентированное проектирование на практике
Стратегический анализ
Осмысление предметной области
Изучение текущего проекта
Определение стратегии модернизации
Стратегическая модернизация
Тактическая модернизация
Развитие единого языка
Паттерн «Душитель» (Strangler)
Рефакторинг тактических проектных решений
Прагматичное предметно-ориентированное проектирование
Как «продать» предметно-ориентированное проектирование?
Законспирированное предметно-ориентированное проектирование
Единый язык
Ограниченные контексты
Тактические проектные решения
Модель предметной области, основанная на событиях
Вывод
Упражнения
ЧАСТЬ IV. Взаимоотношения с другими методологиями и паттернами
ГЛАВА 14. Микросервисы
Что такое сервис?
Что такое микросервис?
Метод как Сервис (Method as a Service): путь к созданию идеальных микросервисов?
Цель проектирования
Сложность системы
Микросервисы как «глубокие» сервисы (deep services)
Микросервисы как глубокие модули
Предметно-ориентированное проектирование и границы микросервисов
Ограниченные контексты
Агрегаты
Поддомены
Сокращение публичных интерфейсов микросервисов
Сервис с открытым протоколом
Предохранительный слой (anticorruption layer, ACL)
Вывод
Упражнения
ГЛАВА 15. Событийно-ориентированная архитектура
Событийно-ориентированная архитектура
События
События, команды и сообщения
Структура
Типы событий
Уведомление
Передача состояния с помощью события
События предметной области (domain event)
Сравнение событий предметной области и уведомлений
Сравнение событий предметной области с ECST-сообщениями
Типы событий: Пример
Проектирование событийно-ориентированной интеграции
Распределенный большой ком грязи
Временнáя связанность (связанность по времени)
Функциональная связанность
Связанность на уровне реализации
Реорганизация событийно-ориентированной интеграции
Творческий подход к событийно-ориентированному проектированию
Предполагайте худшее
Используйте публичный интерфейс и приватные события
Оценивайте требования к согласованности
Вывод
Упражнения
ГЛАВА 16. Сеть данных (Data Mesh)
Сравнение аналитической модели данных (OLAP) с моделью транзакционных данных (OLTP)
Таблица фактов
Таблица измерений
Аналитические модели
Платформы управления аналитическими данными
Хранилище данных — Data Warehouse
Озеро данных — Data Lake
Проблемы архитектур хранилища данных и озера данных
Сеть данных (Data mesh)
Разбиение данных по предметным областям
Данные как продукт
Обеспечение автономии
Построение экосистемы
Совмещение сети данных (data mesh) и предметно-ориентированного проектирования
Вывод
Упражнения
Заключение
Задача
Решение
Реализация
Рекомендуемая литература
Дополнительные сведения о предметно-ориентированном проектировании
Архитектурные и интеграционные шаблоны
Модернизация устаревших систем
EventStorming
Вывод
ПРИЛОЖЕНИЕ 1. Применение DDD: пример из практики
Пять ограниченных контекстов
Предметная область
Ограниченный контекст № 1: Маркетинг
Своеобразная магия
Наши ранние взгляды на предметно-ориентированное проектирование
Ограниченный контекст № 2: CRM
Еще больше «агрегатов»!
Разработка решения: Дубль два
Вавилонская башня 2.0
Более широкий взгляд на предметно-ориентированное проектирование
Ограниченный контекст № 3: Обработчики событий
Ограниченный контекст № 4: Бонусы
Проектирование: Дубль два
Единый язык
Классическое понимание предметно-ориентированного проектирования
Ограниченный контекст № 5: Центр маркетинга
Микро — что?
Реальная проблема
Обсуждение
Единый язык
Поддомены
Сопоставление проектных решений с поддоменами
Не игнорируйте боль
Границы ограниченных контекстов
Вывод
ПРИЛОЖЕНИЕ 2. Ответы на вопросы упражнений
Глава 1
Глава 2
Глава 3
Глава 4
Глава 5
Глава 6
Глава 7
Глава 8
Глава 9
Глава 10
Глава 11
Глава 12
Глава 13
Глава 14
Глава 15
Глава 16
Предметный указатель
Об авторе

Книга посвящена методологии DDD (предметно-ориентированному проектированию), что особенно актуально в условиях дробления предметных областей и усложнения бизнес-взаимодействий. Рассказано, как оценить масштаб и сложность предметной области, измерить темпы её развития, учесть необходимые зависимости, применять событийно-ориентированную архитектуру и структурировать создаваемое ПО, эффективно вписывая его в сеть данных (Data Mesh). Материал будет особенно интересен при развитии стартапа и разработке наукоёмких отраслевых систем.

 Для архитекторов ПО, бизнес-аналитиков и разработчиков корпоративного программного обеспечения  

Сегодня создавать  программное обеспечение стало сложно как никогда. Приходится не только учитывать постоянно меняющиеся технологические тренды, но и понимать ту предметную область (бизнес), для которой оно создаётся.

В этой практичной книге приведён ключевой набор паттернов, принципов и практик для анализа предметной области, понимания стратегий бизнеса и, что самое важное, соотнесение процесса разработки с меняющимися потребностями заказчика.

Автор показывает, как при помощи этих практик надёжно реализовать бизнес-логику, а также обеспечить прочность программной архитектуры на годы вперёд. Вы исследуете, как предметно-ориентированное проектирование (DDD – domain-driven design) соотносится с другими методологиями, и гарантируете, что принимаемые архитектурные решения соответствуют предъявляемым бизнес-требованиям. В книге подробно разобрано внедрение DDD в рамках стартапа.

Вы узнаете, как

• Проанализировать предметную область, в которой работает компания, и определить, как создаваемая система вписывается в эту область и обеспечивает конкурентное преимущество

• Пользоваться стратегическими и тактическими средствами DDD для выстраивания эффективных программных решений, удовлетворяющих потребности заказчика

• Приходить к общему пониманию любой предметной области, с которой приходится иметь дело

• Разбивать систему на ограниченные контексты

• Координировать работу сразу нескольких команд

• Постепенно вводить DDD в реорганизуемые проекты