[Разработка мобильных приложений, Интервью] Очень технический выпуск: про DDD и проектирование сложных систем

Автор Сообщение
news_bot ®

Стаж: 6 лет 3 месяца
Сообщений: 27286

Создавать темы news_bot ® написал(а)
12-Фев-2021 18:35

В свежем выпуске подкаста «Сушите вёсла» обсудили методологии проектирования сложных систем. Много говорили о 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 собираются все заинтересованные лица и на доске с помощью стикеров выстраивают последовательность событий и тех объектов, которые генерируют эти события. Получается некая визуальная карта, в которой становится понятно, как взаимодействуют различные сущности и как они объединяются по контекстам.

Event Storming — фото Daniel GomesИзначально активность проводили офлайн, но сейчас подобное можно спокойно провести онлайн, например, в 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:15CQRS — 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.  Полезные материалы  Предыдущие выпуски подкаста «Сушите вёсла» 
===========
Источник:
habr.com
===========

Похожие новости: Теги для поиска: #_razrabotka_mobilnyh_prilozhenij (Разработка мобильных приложений), #_intervju (Интервью), #_ddd, #_domain_driven_design, #_event_sourcing, #_cqrs, #_podkasty (подкасты), #_blog_kompanii_redmadrobot (
Блог компании Redmadrobot
)
, #_razrabotka_mobilnyh_prilozhenij (
Разработка мобильных приложений
)
, #_intervju (
Интервью
)
Профиль  ЛС 
Показать сообщения:     

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 20-Май 21:57
Часовой пояс: UTC + 5