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