Представьте танец - каждый участник знает свои шаги и реагирует на движения партнёров без указаний хореографа. Но стоит одному из танцоров сбиться или споткнуться, и весь зал погружается в несвязный хаос!
Хореография + Domain-Driven Design: как они сочетаются
Представьте, что ваша система — это оркестр, где каждый музыкант знает свою партию, но никто не машет палочкой. Вместо хаоса — гармония бизнес-процессов. В этом посте разберем, как Domain-Driven Design (DDD) и хореография в распределенных системах создают именно такую синергию: от моделирования событий до масштабируемой архитектуры.
Мертвые события убивают микросервисы: Как Debezium и Outbox-паттерн спасут вашу систему от несогласованности
Ненадежная отправка сообщений — частая причина ошибок в микросервисной архитектуре. Паттерн Outbox решает эту проблему, а Debezium делает его реализацию невероятно простой.
Как организовать гарантированную отправку сообщений в хореографии — паттерн Outbox
При реализации межсервисного взаимодействия с использованием хореографии часто возникает вопрос — как гарантировать доставку сообщений из одной системы (сервиса) в другую?
State Machine и Хореография
В прошлых постах мы разобрали, что такое хореография и как ее реализовывать. А теперь соединим хореографию с паттерном State Machine. Это позволит построить нам прозрачную и управляемую архитектуру.
Как реализовать хореографию на практике
В прошлом посте мы разобрались что такое паттерн "Хореография", его характеристики, когда его можно использовать. Теперь посмотрим, как его реализовать.
Паттерн Хореография: Танцующие Микросервисы
Когда мы строим систему из микросервисов, возникает вопрос: как координировать взаимодействие между ними?
DDD Entity != ORM Entity: Почему это важно и как избежать "болевых точек" в архитектуре
Часто в проектах, которые разрабатываются с использованием подхода Domain Driven Design, возникает соблазн использовать одну и ту же Java сущность для двух принципиально разных целей. Один класс используется и как бизнес логика (DDD Entity), и как ORM сущность (часто это мотивируется следованию принципу DRY(Don't Repeat yourself), хотя он не имеет…
🧭 Statechart и Spring State Machine: когда FSM уже недостаточно
В предыдущем посте мы рассмотрели классические State Machine. Посмотрели на реализацию FSM с использованием таблиц. Но что делать, когда система разрастается и появляются такие требования:
State Machine: когда State уже недостаточно
Паттерн State отлично подходит для управления поведением объекта в зависимости от его состояния. Но что делать, когда логика переходов между состояниями усложняется?
🧠 State ≠ State Machine: разбираем поведенческий паттерн, который часто путают
Хотел написать короткий пост о своём любимом паттерне проектирования. Но пока разбирался — понял, что знаю о нём гораздо меньше, чем думал 😅. В итоге короткий пост превратился в полноценный лонгрид с примерами. Буду публиковать его по кусочкам. Рассказываю, что такое паттерн State, когда его использовать, как не перепутать его с State Machine. 👇