Обзор книги “What Is Domain-Driven Design?”

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

Strategic Design

Analyzing Business Domains

Рис.2 “Типы поддоменов”

Discovering Domain Knowledge

Managing Complexity with Bounded Contexts

Context Mapping

  • partner, когда две команды владеют разными контекстами и могут просто договориться об изменениях в контракте. Причем договороспособность тут двухсторонняя и ни у кого нет переговорной силы форсировать свое решение
  • или shared kernel patterns, когда общие части разных доменов выделяют в отдельную часть и дальше ей владеют несколько команд. В общем и целом, это противоречит подходу с владением одним bounded context одной конкретной командой, поэтому возможны проблемы. Чтобы их не случилось ниже приведена рекомендация по имплементации этого паттерна
Рис. 3 “Схемы взаимодействия в режиме customer-supplier”
  • проблемы в коммуникациях — когда дешевле реализовать самому, чем договариваться с соседней командой
  • система из generic subdomains — в этом случае можно просто поднять инстанс готового решения на своей стороне
  • разница в моделях внутри разных контекстов — дороже выйдет их унификация, чем отдельной развитие
  • High-level design — обзор компонентов системы и моделей, который они реализуют
  • Communication patterns — можно будет увидеть паттерны коммуникации разных команд и предпочтительные паттерны интеграции из перечисленных выше
  • Organizational issues —можно будет увидеть организационные моменты во взаимодействии между consumers и producers

Tactical Design

Business Logic Implementation Patterns

Рис. 4 “Паттерны имплементации бизнес-логики”

Architectural Patterns

  • слоеная архитектура (layered architecture)
  • порты и адаптеры (ports & adapters)
  • command & query responsibility segregation (CQRS)
Рис.5 “Архитектурные паттерны”
Рис.6 “Подробнее про CQRS”

Integration of Bounded Contexts

Рис.7 “Паттерны интеграции”

DDD in Practice

Event Storming

Рис.8 “Шаги техники 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

Evolutionary Design

  • coregeneric, например, когда другая компания выходит на рынок с коробочным решением или SaaS сервисом, который повторяет core логику компании
  • generic core, например, когда стандартная активность внутри компании реализуется так хорошо, что ее можно начать продавать наружу как сервис
  • supporting core
  • transaction script active record
  • active recorddomain model
  • domain modelevent-sourced domain model
  • shared kernelpartnership, так как bounded contexts, принадлежащие раньше одной команде разъезжаются по разным, то имеет смысл переходить к партнерству
  • partnership customer-supplier — по мере роста организации коммуникации между командами слабеют и все сложнее поддерживать партнерские отношения и они переходят к отношениям поставщик-потребитель
  • customer-supplierseparate ways — по мере нарастания коммуникационных проблем схема поставщик-потребитель становится все менее привлекательной и команды переходят к самостоятельному развитию
  • separate wayspartnership or customer-supplier — когда generic или supporting subdomain становится core, появляется потребность унифицировать работу над ним и уйти от его параллельного развития разными командами
  • если domain logic неясна, то проектируй bounded contexts с широкими границами
  • если domain logic стабильна, то проектируй bounded contexts с более узкими границами, которые могут быть реализованы посредством микросервисов

Getting Started

  • Ubiquitous Language
  • Business Domain
  • Context Map
  • Bounded Contexts
  • Event Storming
  • Tactical Patterns: Value Object, Transaction Boundaries, Event-Sourced Domain Model

Итого

Источники

  1. What Is Domain-Driven Design? — book by Vladik Khononov
  2. Introducing EventStorming — book by Alberto Brandolini
  3. Fundamentals of Software Architecture — book by Neal Ford, Mark Richards, ссылка на мой обзор
  4. Domain-Driven Design: Tackling Complexity in the Heart of Software — book by Eric Evans
  5. Domain-Driven Design Distilled — book by Vaughn Vernon

--

--

--

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

DDD — Events Are Complex

CQRS & Event Sourcing III: the framework

Anemic Models vs Rich Models in Domain-Driven Design

When Should You Apply CQRS Software Architecture Pattern?