Сущность в Domain Driven Design — это сердце бизнес-логики. Ее цель - моделирование бизнес-процессов и их жизненного цикла. Сущность инкапсулирует состояние и поведение важное для бизнеса.
💥 Проблемы и подводные камни хореографии
Представьте танец - каждый участник знает свои шаги и реагирует на движения партнёров без указаний хореографа. Но стоит одному из танцоров сбиться или споткнуться, и весь зал погружается в несвязный хаос!
Хореография + Domain-Driven Design: как они сочетаются
Представьте, что ваша система — это оркестр, где каждый музыкант знает свою партию, но никто не машет палочкой. Вместо хаоса — гармония бизнес-процессов. В этом посте разберем, как Domain-Driven Design (DDD) и хореография в распределенных системах создают именно такую синергию: от моделирования событий до масштабируемой архитектуры.
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 с использованием таблиц. Но что делать, когда система разрастается и появляются такие требования:
Saga: когда “отмена” — это не rollback, а новое действие в домене
В мире микросервисов есть одна вечная проблема: как обеспечить согласованность данных между независимыми компонентами? Традиционные транзакции здесь не работают, но есть элегантное решение — Saga-паттерн. Разберем, откуда он произошел, что из себя представляет и почему стал стандартом индустрии.
Мертвые события убивают микросервисы: Как Debezium и Outbox-паттерн спасут вашу систему от несогласованности
Ненадежная отправка сообщений — частая причина ошибок в микросервисной архитектуре. Паттерн Outbox решает эту проблему, а Debezium делает его реализацию невероятно простой.
Как организовать гарантированную отправку сообщений в хореографии — паттерн Outbox
При реализации межсервисного взаимодействия с использованием хореографии часто возникает вопрос — как гарантировать доставку сообщений из одной системы (сервиса) в другую?
Паттерн Хореография: Танцующие Микросервисы
Когда мы строим систему из микросервисов, возникает вопрос: как координировать взаимодействие между ними?
State Machine: когда State уже недостаточно
Паттерн State отлично подходит для управления поведением объекта в зависимости от его состояния. Но что делать, когда логика переходов между состояниями усложняется?