Представьте танец - каждый участник знает свои шаги и реагирует на движения партнёров без указаний хореографа. Но стоит одному из танцоров сбиться или споткнуться, и весь зал погружается в несвязный хаос!
Представьте танец - каждый участник знает свои шаги и реагирует на движения партнёров без указаний хореографа. Но стоит одному из танцоров сбиться или споткнуться, и весь зал погружается в несвязный хаос!
👩💼 Менеджеры любят видеть процесс целиком: от старта до результата. Но в хореографии это сложно - сервисы общаются напрямую, и картина теряется. 🎯 Оркестрация делает процесс прозрачным: бизнес и архитекторы видят одну и ту же модель, которую можно и читать, и исполнять.
Представьте, что ваша система — это оркестр, где каждый музыкант знает свою партию, но никто не машет палочкой. Вместо хаоса — гармония бизнес-процессов. В этом посте разберем, как Domain-Driven Design (DDD) и хореография в распределенных системах создают именно такую синергию: от моделирования событий до масштабируемой архитектуры.
В прошлом посте мы разобрались что такое паттерн "Хореография", его характеристики, когда его можно использовать. Теперь посмотрим, как его реализовать.
Perforator — это система непрерывного профилирования (continuous profiling), разработанная в Яндексе. Она помогает отслеживать, какие участки кода потребляют ресурсы в продакшене, с минимальной нагрузкой на сервисы. Система уже используется на сотнях сервисов внутри компании, а с недавнего времени доступна как проект с открытым исходным кодом.Проек…
В прошлом посте мы разобрали классический вариант реализации Active Record. Обсудили, когда стоит переходить от Transactional Script к Active Record.
В прошлом посте мы разбирали Transactional Script - отличный инструмент для старта. Но любой проект развивается. Со временем вы начинаете замечать, что Transactional Script становится сильно усложненным. В них добавляются простые бизнес-инварианты, дополнительные проверки и сами структуры данных становятся довольно сложными.
Ваша система начинает тонуть в хаосе обработки бизнес-процессов, хотя каждый сервис работает отлично "как часы". Простые цепочки вызовов и реакций на события, обработка компенсаций превращается в запутанную, хрупкую и не поддающуюся тестированию архитектуру.
В мире распределенных систем существует множество подходов к управлению процессами и согласованностью данных. Часто для управления согласованностью применяют подходы, предназначенные для управления процессами, и наоборот. Часто вследствие неправильного применения подходов распределенные системы становятся неуправляемыми.
В распределенных системах, помимо задач управления данными и транзакциями, существуют задачи управления самими процессами. Бывают сложные сценарии с множеством ветвлений, условиями, повторными попытками, откатами и длительными ожиданиями. В таких случаях уже невозможно либо очень трудно использовать простые цепочки вызовов и реакцию на события, это…
Когда мы слышим Domain Driven Design, на ум сразу приходят такие понятия, как Ubiquitous Language (Повсеместный/Всеобщий язык), Bounded Contexts (Ограниченные контексты), то есть чаще всего говорят о стратегическом дизайне.
Кэш — механизм, который часто используют как «волшебную кнопку» для ускорения системы — достаточно добавить Redis, и всё работает быстрее. Есть обманчивое восприятие механизма кэширования — будто мы можем радикально изменить производительность системы, снизить затраты на инфраструктуру и даже повлиять на бизнес-метрики.