Обзор книги “Learning Domain-Driven Design” — part I

Сегодня я решил подвести итог нашим обсуждениям книги “Learning DDD”, которую мы обсуждали последние 2 месяца в рамках нашего книжного клуба любителей архитектуры Code of Architecture. Итог подведен в четырех частях

• В этой статье представлена первая часть обзора, которая включает в себя обзор первых трех частей книги: Strategic Design, Tactical Design и Applying DDD in Practice
• Вторая часть содержит обзор взаимосвязь с microservices
• Третья часть содержит рассказ про event-driven architecture
• А в последней части речь идет про data mesh

Забавно, что сама состояла из четырех частей, которые приведены на рисунке ниже.

Рис.1 “Содержание книги”

На всю книгу у нас вышло 6 встреч, которые доступны по ссылкам ниже

• Strategic Design — обсуждение первой части книги, а именно подходов к анализу бизнес-доменов организации, управлению сложностью доменов и интеграции bounded contexts
• Tactical Design — Part 1 — обсуждение первой половины второй части книги, где рассматриваются варианты реализации бизнес-логики от самых простых, до самых продвинутых
• Tactical Design — Part 2 — обсуждение первой половины второй части книги, а именно архитектурных паттернов и паттернов коммуникации
• Applying Domain-Driven Design in Practice — обсуждение третьей части книги, в которой рассматриваются эвристики проектирования, эволюционирование проектировочных решений во времени, техника Event Storming и то, как DDD постепенно добавлять к существующим brown-field проектам
• Relationships to Other Methodologies and Patterns — обсуждение последней, четвертой части книги, а именно вопросов связанных с микросервисами, событийно-ориентированной архитектуры (event-driven architecture) и работе с аналитическими данными при помощи data mesh
• Финальная встреча с автором книги Vladik Khononov и обсуждение вопросов зрителей, накопившихся с предыдущих пяти встреч

Кстати, до этого у Влада уже был отчет “What is DDD”, о котором яуже рассказывал больше года назад. Этот отчет вырос в объеме в 3 раза и превратился в полноценную книгу и я сравнивал их содержание в отдельной статье. Но теперь пришло время для полноценного обзора книги “Learning DDD”

Strategic Design

Эта часть отлично подходит как для разработчиков, так и для представителей бизнеса. В ней рассказывается про классификацию business subdomains, которые есть в каждой компании.

Рис.2 “Business Subdomains”

Про единый язык (ubiquitous language), который един в пределах ограниченного контекста (bounded context), которых в организации может быть много. Этот язык используется для обмена знаниями и именно на нем говорят доменные эксперты и в лучшем случае даже исходный код:)

Интересно, что business subdomains — это нечто присущее самой компании и нам надо просто выяснить какие subdomains есть, а вот как выбрать границы для bounded contexts — уже на совести проектировщика и есть целый ряд эвристик для выбора этих границ.

Отдельная глава посвящена тому, как правильно выстроить взаимодействие между командами, отвечающими за разные bounded contexts. Вариантов несколько и они представлены на рисунке ниже.

Рис.3 “Team Collaboration Patterns”

И для анализа конкретных взаимоотношений этих контекстов внутри организации можно использовать context map .

Tactical Design

Эта часть начинается с вариантов реализации бизнес-логики от самых простых, до самых продвинутых. Все они представлены на рисунке ниже

Рис.4 “Implementation of Business Logic”

Автор рассматривает их по порядку, рассказывая про преимущества и недостатки каждого из подходов, а также указывая границы применимости.

Дальше автор переходит к архитектурным паттернам, которые помогают организовать взаимодействие между компонентами системы. Начинает он рассказ с layered architecture, дальше рассматривает ports & adapters (clean architecture) и заканчивает рассмотрением CQRS.

Рис.5 “Architecture Patterns”

Каждый из этих архитектурных подходов описывается достаточно подробно, отмечаются сильные и слабые стороны, а также границы применимости.

Ну и заканчивается эта глава рассказам про паттерны коммуникации между bounded contexts. И начинается все с того, как можно транслировать модели разных контекстов друг в друга. Вообще это требуется делать только при варианте взаимодействия customer-supplier и в случае реализации подхода anti corruption layer или open-host principle

Рис.6 “Model Translation Patterns”

Паттерны интеграции агрегатов выглядят следующим образом. Основная цель в том, чтобы консистентно менять состояние, размазанное по разным агрегатам, а значит и проходящее через транзакционные границы.

Рис.7 “Patterns of integrating Aggregates”

Applying Domain-Driven Design in Practice

Третья часть книги посвящена тому, как применять изученные подходы на практике и какие эвристики могут помочь делать это наиболее эффективно. Автор так определяет эвристики

A heuristic is not a hard rule … rather, it’s a rule of thumb: not guaranteed to be perfect, yet sufficient for one’s immediate goals.

И приводит такое дерево решений

Рис.8 “Tactical Design Decision Tree”

Оно наглядно связывает:

• Subdomain type
• Варианты имплементации бизнес-логики
• Архитектурные паттерны
• Стратегии тестирования

Конечно бывают и исключения, но в основном для принятия решений можно пользоваться приведенным на рисунке алгоритмом.

Дальше автор рассказывает о том, что со временем все течет и меняется, поэтому должны меняться и наши дизайн решения. Автор выделяет следующие причины изменений

Рис.9 “Vectors of change”

Больше всего внимания автор уделяет изменениям в бизнес-доменах

Рис.10 “Subdomain type change factors”

Изменения в типах subdomains напрямую влияют на bounded contexts, а значит и на соответствующие стратегические дизайн решения, например, как интегрировать и развивать различные bounded contexts. Также меняются и тактические дизайн решения, а на какие именно можно узнать на рисунке с tactical design decision tree. Интересно, что в этой главе автор описывает как эти изменения можно реализовать эволюционно, а именно

• Как переходить от transaction script к active record
• Как переходить от active record к domain model
• Как и когда переходить от простой domain model к event-sourced domain model

Дальше рассматриваются организационные изменения, которые обычно влияют на team collaboration patterns. Обычно это выглядит как переход

• от partnership к customer-supplier
• или от customer-supplier к separate ways

Дальше автор говорит о том, что по мере изменений в наших знаниях о домене, мы можем уходить от широких bounded contexts в сторону более узких, которые можем реализовывать при помощи microservices. Вообще связи DDD и microservices посвящена целая глава.

Ну и последний вектор изменений связан с ростом, который происходя неконтролируемо приведет вашу систему в состояние Big Ball of Mud (возможно distributed).

Последняя глава этой части посвящена технике Event Storming, которая является групповой техникой моделирования для упрощения процесса получения знаний о домене и формировании ubiquitous language. Шаги этого процесса представлены ниже. Интересно, что цвета шагов совпадают с рекомендованными цветами стикеров для карточек, которые в основном используются на каждом шаге.

Рис.11 “Шаги техники event storming”

Пройдемся по этим шагам:

• unstructured exploration — на этом шаге в режиме брейншторма все участники группы самостоятельно накидывают на доску domain events
• timelines — сгенерированные на предыдущем шаге domain events выстраиваются в хронологическом порядке, начиная с happy path
• commands — на этом шаге добавляются commands, которые описывают что именно триггерит событие или поток событий. У части команд есть actor, который и запускает выполнение команды
• policies — на этом шаге идет разбор команд, которые не имеют actor. У таких команд есть policy, когда запускается такая команда, обычно она завязана на наступление какого-то другого domain event
• external systems — на этом шаге модель расширяется внешними системами, которые не являются частью домена, что разбирается, но которые участвуют в процессе, например, исполняют command или получают нотификации о domain events
• aggregates — когда все команды и события на месте, участники могут начать задумываться об оптимизации и выделении aggregates, которые получают команды и генерируют события
• bounded contexts — на последнем шаге время посмотреть на всю картину. Группы тесно связанных aggregates являются естественными кандидатами на определение границ для bounded contexts

В общем, Event Storming является очень хорошим инструментом для совместного моделирования сложной предметной области .

Последняя глава этой части посвящена тому, как применять DDD в реальном мире.

Рис.12 “Domain-Driven Design in the Real World”

По-факту стоит начать со стратегического анализа:

• Разобраться кто является потребителями продуктов компании, какие сервисы она предоставляет и с кем конкурирует. Также следует понять какие business subdomains в компании есть
• Дальше требуется разобраться с текущим дизайном. Понять какие тактические паттерны применены, например, какая архитектура выбрана для основных систем, а также как связаны контексты. Для этого можно построить context map

Дальше стоит перейти к стратегии модернизации, где требуется мыслить масштабно, но двигаться маленькими шагами

• Начинать надо с организации логических границ систем
• Дальше оценивать превращение каких логических границ в физические даст больше пользы
• Учитывать, что при разделении bounded contexts нам хорошо бы правильно организовать их общение через соответствующие случаю паттерны интеграции, которые можно посмотреть на рисунке “Team Collaboration Patterns”
• Дальше нам надо развивать ubiquitous language, как в качестве средства общения людей внутри компании, так и для кода — идеально, если код тоже будет оперировать сущностями ubiquitous language
• Для эволюционной замены частей системы может пригодиться strangler pattern, про который подробнее можно прочитать здесь

Вообще, в реальном мире мы должны подходить к внедрению Domain Driven Design прагматично. Как говорит об этом Влад

Domain-driven design is about letting your business domain drive software design decisions.

Ну и напоследок Влад объясняет как продавать domain driven design без отсылок к Эвансу или Вернону или к нему самому. Для этого он приводит объяснения в форме наводящих вопросов про польщзу

• ubiquitous language
• bounded context
• tactical design patterns
• и event-sourced domain model

Последняя часть этой замечательной книги посвящена связи с другими методологиями

• microservices
• event-driven architecture
• data mesh

Эти вопросы настолько обширны и интересны, что я расскажу про них в следующих статьях:

• DDD & Microservices
• DDD & EDA
• DDD and Data Mesh