Моделирование микросервисов с помощью Event Storming / Сергей Баранов (ScrumTrek)

• История начинается в 2005 году, когда автор, программист с опытом работы на C и ассемблере, сталкивается с необходимостью архитектурного проектирования.  

• В то время не было книг по архитектуре, и автор самостоятельно изучает тему.  

• Он замечает, что проектирование архитектуры занимает много времени и не всегда работает для крупных проектов.  

• Автор сталкивается с полярными ситуациями: отсутствие архитектуры и длительные циклы проектирования.  

• Он начинает изучать DDD и инкрементальную архитектуру, но это не дает полного видения.  

• Книги по антихрупкой архитектуре и микросервисам помогают, но не решают проблему.  

• Архитектор должен быть экспертом во всех областях, но это сложно.  

• Декомпозиция архитектуры по модели "четыре си" Саймона Брауна помогает, но не решает проблему для нескольких предметных областей.  

• Возникает проблема, что никто не понимает, как работает система в целом.  

• Альберт Брандолини объясняет, что в разработку идут предположения, а не знания.  

• Когнитивные искажения и лень мешают точному пониманию требований.  

• В микросервисной архитектуре это становится критически важным, так как рефакторинг затруднен.  

• В 2016 году автор находит книгу и выступление по ивентормингу, которое решает проблему.  

• Ивенторминг позволяет быстро и эффективно строить общее видение архитектуры.  

• Это помогает сделать команды более автономными и независимыми.  

• Ивенторминг собирает разработчиков и экспертов для совместного исследования.  

• Процесс начинается с хаоса, но со временем определяется четкая структура.  

• Автор проводил ивенторминг около 30 раз, и это всегда было эффективно.  

• Клиент выполняет команды, например, добавляет товар в корзину.  

• Команды могут быть отменены, и они приходят в агрегат из DDD или внешней системы.  

• Агрегат или внешняя система порождают события, которые могут активировать бизнес-правила.  

• В домене происходят сотни или тысячи событий.  

• События связаны с командами, например, добавление товара в корзину.  

• Бизнес-правила помогают перевести бизнес-логику в код.  

• Агрегаты — это сущности, которые рассматриваются как единое целое.  

• Агрегаты отвечают за целостность данных и являются транзакционными границами.  

• В начале можно собирать команды и события вокруг агрегатов, не заполняя их полностью.  

• Агрегаты образуют ограниченные контексты, которые должны быть автономными.  

• Автономность помогает создавать независимые микросервисы.  

• Пример показывает, как со временем появляется структура и автономность.  

• Пример показывает, как генерируются события, команды и бизнес-правила.  

• Со временем команды и события собираются в контексты работы с ботами, диалога и закрытия.  

• Ограниченные контексты помогают создать автономные микросервисы.  

• Ограниченные контексты создают встроенную структуру.  

• Пример включает около 40 человек, разделенных на четыре группы.  

• Агрегаты могут разрабатываться и поставляться автономно, что ускоряет процесс.  

• Данные оцифровываются и складываются в общую базу знаний, доступную всем сотрудникам.  

• Рассматриваются четыре контекста: поиск, экспертиза, авторизация и загрузка справочников.  

• Контексты делятся на три типа: основной, поддерживающий и общий.  

• Важно определить, какие контексты требуют внутренней разработки, а какие можно отдать на аутсорс.  

• Контексты оцениваются по их сложности и стоимости реализации.  

• Контексты с высоким конкурентным преимуществом и сложностью реализации считаются основными.  

• Контексты с низким конкурентным преимуществом и низкой сложностью считаются поддерживающими.  

• Основные усилия сосредоточены на контекстах с высоким конкурентным преимуществом.  

• Поддерживающие контексты могут быть отданы на аутсорс или переданы джуниорам.  

• Дженерик-контексты можно повторно использовать или купить готовые решения.  

• Определяются нефункциональные требования, такие как частота обращений и пропускная способность.  

• Рассматриваются интеграционные связи и объемы передаваемых данных.  

• Важно защитить предметную область экспертизы от специфичных для авторизации данных.  

• Контексты строятся так, чтобы они были автономными.  

• Внутри каждого контекста можно использовать легковесные подходы, такие как 4C.  

• Команды самостоятельно проводят декомпозицию и принимают инженерные решения.  

• Команды могут выбирать базы данных и технологии в рамках заданных ограничений.  

• Важно, чтобы решения принимались внутри контекста и не влияли на другие команды.  

• Интерфейс должен быть четко определен для внешнего мира.  

• Сервисы строятся вокруг бизнес-потребностей и развертываются независимо.  

• Шторм позволяет быстро определить бизнес-потребности и перейти к техническим решениям.  

• Шторм закрывает пробел между биг-дизайном и инкрементальным дизайном, позволяя быстро и автономно создавать независимые контексты.  

• Эмишторник помогает быстро получить стратегический дизайн.  

• Команды могут самостоятельно принимать решения по развитию микросервисов.  

• Зависимости и технический долг тормозят разработку, но эмишторник помогает их избежать.  

• Возможность легко скидывать технический долг и заменять сервисы.  

• Шторм не является одноразовой сессией, а требует периодического обновления.  

• Поддержание общего видения и ментальной модели помогает избежать когнитивных искажений.  

• Вопрос о количестве участников в вен шторминге: максимум 50 человек.  

• Участники делятся на группы по предметным областям и выгружают свои идеи.  

• Важно участие бизнес-людей, которые понимают бизнес-контекст.  

• Участие бизнес-людей и технических специалистов обязательно.  

• Начинать лучше с бизнес-модели, чтобы избежать технических деталей.  

• Техническая архитектура может меняться, в отличие от бизнес-модели.  

• Стена должна быть достаточно большой, чтобы вместить все события.  

• Первое событие лучше размещать в середине стены.  

• Начинать лучше с простых кейсов, чтобы участники втянулись и начали генерировать события.  

• Вопрос от слушателя из Zoom о том, как перейти от неправильной микросервисной архитектуры к правильной.  

• Обсуждение необходимости абстрагирования от текущей архитектуры и создания модели предметной области.  

• Перенос сущностей между микросервисами для повышения их автономии.  

• Важность моделирования без привязки к текущей архитектуре.  

• Создание модели предметной области для стратегического дизайна.  

• Перенос кода между микросервисами для повышения автономии.  

• Моделирование и создание прототипов для перехода.  

• Использование вики для описания ограниченных контекстов.  

• Переход к новой архитектуре может быть быстрым и эффективным.  

• Важность правильного определения границ микросервисов.  

• Ограниченные контексты и их границы.  

• Появление границ микросервисов по мере наполнения деталями решения.  

• Четыре уровня изоляции в микросервисах.  

• Проверка архитектуры на соответствие принципам изоляции.  

• Стратегия моделирования крупных блоков и их постепенного разделения.  

• Начало с крупных блоков для модульного монолита.  

• Переход на микросервисы по мере необходимости.  

• Важность хорошего модульного монолита перед переходом на микросервисы.  

• Эншторминг - это сессия, которую нужно повторять периодически.  

• Частота проведения зависит от скорости изменения бизнеса.  

• В молодых бизнес-моделях сессии проводятся чаще, в стабильных - реже.  

• Триггеры обычно возникают, когда уже нужно что-то менять.  

• Сессии полезны даже без значительных изменений.  

• Возможность продолжить обсуждение в дискуссионной зоне.  

• Вопросы в чате пока немногочисленны.  

• Пример компании, которая часто перестраивает структуру микросервисов.  

• Перестроения ведут к организационным изменениям и всплеску ошибок.  

• Команды должны быть стабильными для эффективной работы.  

• Микросервисы и организационная структура меняются в зависимости от динамики бизнеса.  

• Молодые бизнесы часто меняют модели и микросервисы.  

• Микросервисы позволяют разбить сложную предметную область на управляемые кусочки.  

• Сложность инфраструктуры микросервисов может быть высокой.  

• Монолитные решения могут быть более подходящими для простых предметных областей.  

• Сергей отвечает на вопрос из чата о сложном примере ивент-шторминга.  

• Он предлагает проводить сессии для лучшего понимания метода.  

• Пример из презентации показывает, как можно организовать такие сессии.  

• Ивент-шторминг помогает в документировании требований пользователей.  

• Команды и события можно группировать по кейсам.  

• Важно использовать канвасики для сбора информации по контекстам.  

• Агрегаты — это логические сущности, которые включают другие сущности и события.  

• Пример: сущность "заказ" включает товары и адрес доставки.  

• Агрегат следит за целостностью данных и бизнес-правилами.  

• Агрегаты помогают управлять данными на уровне модели предметной области.  

• Пример с пользователями: участник и спикер — это разные агрегаты.  

• В разных контекстах данные могут быть разными, и агрегаты следят за их целостностью.  

• В контексте редактирования статьи используется сущность "драфт".  

• После публикации создается новая сущность для просмотра статьи.  

• Пример с докладами на конференциях: драфт доклада можно редактировать, а опубликованный доклад — нет.  

• Драф можно редактировать, но описание доклада на сайте не меняется.  

• Ограниченные контексты формируются вокруг событий, которые переводят сущности из одной терминологической базы в другую.  

• Пример: событие "доклад опубликован" создает новую сущность "опубликованный доклад".  

• В разных контекстах используются разные терминологии.  

• Пример из страховой компании: разные термины для застрахованных в зависимости от гражданства.  

• Архитекторы часто работают с терминологией больше, чем с технической архитектурой.  

• Важно слушать, как люди называют сущности в разных контекстах.  

• Пример с документом: разные свойства в контексте редактирования и печати.  

• Границы контекста определяются событиями, которые переводят сущности из одного словарика в другой.  

• Возможность задавать вопросы и практиковаться в телеграме.  

• Вопрос о документации и агрегаторах.  

• Важность понимания терминологии и контекста для успешной работы.