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

  • В этой статье представлена первая часть обзора, которая включает в себя обзор первых трех частей книги: Strategic Design, Tactical Design и Applying DDD in Practice
  • Вторая часть содержит обзор взаимосвязь с microservices
  • Третья часть содержит рассказ про event-driven architecture
  • А в последней части речь идет про data mesh
Рис.1 “Содержание книги”
  • 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 и обсуждение вопросов зрителей, накопившихся с предыдущих пяти встреч

Strategic Design

Рис.2 “Business Subdomains”
Рис.3 “Team Collaboration Patterns”

Tactical Design

Рис.4 “Implementation of Business Logic”
Рис.5 “Architecture Patterns”
Рис.6 “Model Translation Patterns”
Рис.7 “Patterns of integrating Aggregates”

Applying Domain-Driven Design in Practice

Рис.8 “Tactical Design Decision Tree”
  • Subdomain type
  • Варианты имплементации бизнес-логики
  • Архитектурные паттерны
  • Стратегии тестирования
Рис.9 “Vectors of change”
Рис.10 “Subdomain type change factors”
  • Как переходить от transaction script к active record
  • Как переходить от active record к domain model
  • Как и когда переходить от простой domain model к event-sourced domain model
  • от partnership к customer-supplier
  • или от customer-supplier к separate ways
Рис.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
Рис.12 “Domain-Driven Design in the Real World”
  • Разобраться кто является потребителями продуктов компании, какие сервисы она предоставляет и с кем конкурирует. Также следует понять какие business subdomains в компании есть
  • Дальше требуется разобраться с текущим дизайном. Понять какие тактические паттерны применены, например, какая архитектура выбрана для основных систем, а также как связаны контексты. Для этого можно построить context map
  • Начинать надо с организации логических границ систем
  • Дальше оценивать превращение каких логических границ в физические даст больше пользы
  • Учитывать, что при разделении bounded contexts нам хорошо бы правильно организовать их общение через соответствующие случаю паттерны интеграции, которые можно посмотреть на рисунке “Team Collaboration Patterns”
  • Дальше нам надо развивать ubiquitous language, как в качестве средства общения людей внутри компании, так и для кода — идеально, если код тоже будет оперировать сущностями ubiquitous language
  • Для эволюционной замены частей системы может пригодиться strangler pattern, про который подробнее можно прочитать здесь
  • ubiquitous language
  • bounded context
  • tactical design patterns
  • и event-sourced domain model
  • microservices
  • event-driven architecture
  • data mesh

--

--

--

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Alexander Polomodov

Alexander Polomodov

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

More from Medium

Microservices did you know this ?

Domain Driven Design— Solving the problems for solutions

Do you perform reviews?

Command query responsibility segregation(CQRS) with Event sourcing, The basics.