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