Complexity is the Gotcha of Event-driven Architecture • David Boyne • GOTO 2024 (Рубрика Architecture)
Интересное выступление от David Boyne, Senior Developer Advocate at AWS, который рассказывает в своем докладе про преимущества и недостатки event-driven architecture (EDA). Суть в том, что сложность присуща архитектуре, управляемой событиями, сразу с самого начала, но если использовать правильные подходы, то по мере роста системы эта сложность не увеличивается настолько быстро, как при других подходах к проектированию. Собственно автор выстраивает свое выступление следующим образом
- Сначала он рассказывает про потенциал EDA - как EDA делает архитектуру эволюционной, а не статичной:)
- Потом он рассказывает про guardrails для того, чтобы справляться со сложностью EDA
- Как можно обосраться с EDA
Потенциал EDA можно увидеть, построив график по двум осям: size и time. Дальше на графике надо отобразить решения, которые надо принимать, а также знания, которые у нас имеются для этого. Суть в том, что в начале проекта знаний у нас мало, а решения нам надо принимать крупные. Это называется "project paradoxon", для решения которого нам надо уметь откладывать крупные решения до получения нужного количества знаний ... или учиться быстрее. Но, принимая решения без нужного количества знаний, мы часто оказываемся в условиях статичной архитектуры, которая характеризуется свойствами: tightly coupled, low cohesion, resistance to experimentation, team interdependency. В противовес этому автор утверждает, что использование EDA позволяет создать эволюционную архитектуру (как в книге "Building evolutionary architecture", подробнее здесь), у которой как говорит автор есть свойства: loosely coupled, high cohesion, platform to experiment, team dependency. К тому же она
- Позволяет создавать компоненты, которые можно менять местами в зависимости от ситуации.
- Повышает качество кода и позволяет экспериментировать.
- Может привести к инновациям, но также увеличивает сложность.
Дальше автор показывает как определить события, а дальше как начать им обмениваться между producers и consumers. Дальше это все начинает эволюционировать и легко получить ад из разных событий, разных producers и consumers и с отсутсвием любого понимания о том, как все это работает:) Для решения этих проблем автор предлагает использовать guardrails
- Behavior vs implementation - начинать надо не с деталей имплементации, а с поведения системы. Здесь автор вспоминает про Альберто Брандолини и его подход Event storming, про которую я уже вспоминал. Эта техника позволяет начать с событий внутри системы, а в итоге понять ее поведение и заодно разобраться с bounded contexts:)
- Event evolution strategy - при старте EDA проекта надо подумать про эволюцию событий. Автор приводит метафору о том, что events рассказывают историю, а tables - описывают состояния прямо сейчас. Автор предлагает контролировать сложность схемы событий через обратную совместимость, опциональные поля и параллельные версии событий
- Define coupling strategy - это можно сделать через использование в консьюмерах подходов conformist, ACL (anti-corruption layer) и open-host principle (хорошо описано в книге "Learning DDD", подробнее здесь). Тут же автор предлагает разделять public и private events - внутри домена или между ними
Но самая большая проблема в том, что есть мантра
Producers should not know about consumers приводит к тому, что управлять этой системой по мере эволюции становится невозможно. Поэтому автор предлагает использвать следующие инструменты
- cloudevents - cпецификация для общего описания данных о событиях.
- AsyncAPI - фактически, OpenAPI для асинхронных API
- EventCatalog.dev - open source проект автора с описанием, который помогает документировать сообщения, команды, запросы и события, а также создавать версии доменов и служб.
Напоследок автор говорит о том, что сложность будет присутствовать независимо от того, нравится она или нет, и что важно уметь справляться с ней ... при помощи guardrails
#Architecture #SoftwareArchitecture #DDD #SystemDesign #DistributedSystems