Очень технический выпуск: про DDD и проектирование сложных систем

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

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

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 — с чего начать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А подробно рассказали с 1:10:00.

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

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

#приложения #проектирование #ddd #интервью #подкасты #redmadrobot #karuna