В свежем выпуске подкаста «Сушите вёсла» обсудили методологии проектирования сложных систем. Много говорили о Domain Driven Design, Event Sourcing и CQRS. Тема непростая, но, как говорится, очень интересная. 

Артём Кулаков и Рома Чорыев — разработчики Redmadrobot, они записывают подкаст, где обсуждают различные стороны создания ИТ-продуктов. Ниже ссылка на новый выпуск, тайминг и ответы на душещипательные вопросы. Но вначале небольшой дисклеймер: 

Почему все больше и больше ведется разговоров о различных аспектах и методологиях проектирования систем? Потому что наши системы стали действительно большими. Чтобы разобраться, как проектировать такие системы, мы позвали Алексея Мерсона — системного архитектора из Karuna. В выпуске попробовали разобраться, что такое Domain Driven Design, как он связан с Event Sourcing и при чем тут CQRS и микросервисы. Снять удалось только первый слой, да и то неравномерно. Но всем, кто хочет начать погружаться в тему, этот выпуск будет несомненно полезен. И обязательно ознакомьтесь с материалами к выпуску.

Тайминг 

02:29 — Гость студии Алексей Мерсон и как он начинал;

05:02 — .Net и DDD;

12:26 — почему сейчас все чаще говорят о DDD;

15:30 — полезная литература о DDD;

23:01 — как начать проектировать систему по DDD;

25:05 — Event storming и Miro;

45:15 — что такое Event sourcing;

55:00 — CQRS и его связь с DDD и Event sourcing;

01:06:10 — с чего начать.

DDD — что это и почему сейчас?

Domain-Driven Design — предметно-ориентированное проектирование. Понятие известно давно, но в последнее время в русскоязычном сообществе о нем говорят всё чаще.

Алексей считает, что возможно, это связано с тем, в Agile-мире запускаются проекты, которые без применения DDD «скатятся в печальное состояние», потому что появится расхождение между предметной областью и реализацией.

В первую очередь Domain-Driven Design — это история о проектировании, и предметная область в нем ставится во главу угла. И основной акцент в этом подходе делается на взаимодействии с бизнесом — с заказчиками ПО и приложений. 

Если проще, то бывает, что для решения бизнес-задач «конвейер производства ПО» растягивается, и в конечном счете в реализации решения этих задач могут оказаться совсем не такими, какими задумывались изначально. И вот тут, чтобы не играть в «испорченный телефон», применяется DDD. Его цель — сократить расстояние между бизнесом и разработчиками, чтобы последние максимально точно понимали, что за бизнес-процессы они реализуют.

Как спроектировать сложную систему с нуля? 

В студии прозвучал резонный вопрос: «представим, что мы поняли, что у нас сложная система, которую будем делать по DDD и у нас на это даже есть много времени. С чего стоит начать?» Алексей дал несколько советов.

Первое — конечно же, придется стартовать с MVP, то есть с «маленьких кусочков», которые затем будут «разрастаться» во что-то большее. Второе — понять процессы, которые нужно автоматизировать. При этом важно находиться в контакте с теми, кто ставит задачи. Например, с продактами или с кем-то из бизнеса, топ-менеджерами. Дальше — расписать сценарии таким образом, чтобы стал понятен контекст, в котором существуют заданные бизнес-процессы. 

И, кстати, многие для этих целей используют системой Event storming — это такой способ собрать разработчиков и бизнес-экспертов в одном месте, чтобы вместе исследовать предстоящую разработку. 

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

Изначально активность проводили офлайн, но сейчас подобное можно спокойно провести онлайн, например, в Miro. 

Event Sourcing (не путать с Event storming)

Event Sourcing — еще одна популярная сегодня тема. Это архитектурный  шаблон, упоминание которого часто всплывает в связи с DDD. 

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

Недавно в сообществе SpbDotNet был митап, где рассказывали о том, как одна команда применяла Event Sourcing. Они применяли его в  приложении, которое реализовывало аукционы. Там есть ставки, и они, по сути, являются событиями, которые конкурируют: важно, в какой момент каждое из них произошло, важно получить из них правильную последовательность, чтобы понять конечный статус агрегата, например, лота или аукциона. И в этой ситуации Event Sourcing вполне оправдан.

Но иногда случается, что Event Sourcing — это просто ненужное усложнение процесса. Ведь его легко сделать неправильно и очень сложно сделать правильно, потому что в нем есть много мест, где можно «свернуть не туда».

Event Sourcing лучше всего применять в конкурентных и неизменяемых историях, говорит Алексей. Классическое место для этого шаблона — финансовые транзакции. Есть финансовые события: зачисления или списания, — и разработчику важно, чтобы их последовательность была, во-первых, четкой. Во-вторых, ее невозможно было отменить — необходим однозначный конечный баланс. И Event Sourcing дает возможность сделать это так, чтобы цепочка событий всегда шла только вперед.

Подробнее обо всём начинается с 45:15

CQRS — yay or nay?

Ребята обсудили, что CQRS — это, скорее, паттерн, применяемый в технической области. Связан ли CQRS и DDD?

DDD больше заточено на side effects и изменения, а CQRS больше относится к отображению. И это его качество, как раз, применяется в Event Sourcing, потому что фактически есть только набор ивентов, а показывать, как правило, нужно данные, состояния объектов. А для того чтобы данные эти получить, нужно из ивентов делать проекции. В общем, если смотреть на CQRS под этим углом, получается история о синхронном взаимодействии с точки зрения UI/UX.

Подробное обсуждение этого непростого вопроса — с 55:00.

Где и как научиться всему этому?  (желательно до выхода на пенсию)

Алексей посоветовал начать с его доклада. Он подметил,  что «для того и рассказывал, чтобы дать интро по теме». 

Кроме того, стоит почитать книги из списка полезных материалов, который будет дальше. В студии согласились с тем, что лучше начать читать что-то более общее и лёгкое, чтобы просто понять принципы. А дальше можно переходить к более сложным и подробным книгам, например, к «синей книге» Эрика Эванса. 

Можно ещё подписаться на сообщество DDDevotion и спросить там обо всем, что интересует. Подписчики могут проконсультировать в самых разных вопросах, — например, как применять DDD в PHP, а также в других стэках. 

Под конец разговора Рома ещё задал интересный вопрос: «Kакая проблема должна стоять перед разработчиком, чтобы он понял, что пришло время углубиться в DDD?» Если коротко, то сложно ответить коротко :) А подробно рассказали с 1:10:00.  

Полезные материалы 

• Доклад про суть DDD;

• Зеленая книга Вернона (для начала);

• Красная книга Вернона (для погружения);

• Синяя книга Эванса (для полного просветления);

• Patterns, Principles, and Practices of Domain-Driven Design;

• Полезная книга по DDD для .NET-чиков;

• Проектирование событийно-ориентированных систем,

• Про CQRS/CQS и возврат результата командой.

Предыдущие выпуски подкаста «Сушите вёсла» 

• Архитектор ПО: зачем он нужен и в чём его проклятие;

• Источник правды: как аналитик учит менеджера и разработчика работать вместе;

• CTO всея стартапа QA для начинающих: как протестировать ракету или самолёт;

• Очередь в backend: за чем стоим и с чего начать свой путь;

• Пандемия и ИТ-бизнес: как адаптироваться, и что делать дальше.

Слушайте нас там, где удобно: Soundcloud, Apple Podcasts, Google Podcasts

Давайте обсудим выпуск в Telegram-чате.