В свежем выпуске подкаста «Сушите вёсла» обсудили методологии проектирования сложных систем. Много говорили о 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.
Полезные материалы
Предыдущие выпуски подкаста «Сушите вёсла»
Источник правды: как аналитик учит менеджера и разработчика работать вместе;
CTO всея стартапа QA для начинающих: как протестировать ракету или самолёт;
Пандемия и ИТ-бизнес: как адаптироваться, и что делать дальше.
Слушайте нас там, где удобно: Soundcloud, Apple Podcasts, Google Podcasts
Давайте обсудим выпуск в Telegram-чате.
