Основы фреймворка enode

Enode — это приложение, созданное на основе платформы JVM для реализации бизнес-практик Domain Driven Design. Оно использует паттерны CQRS и Event Sourcing, что позволяет разработчикам сосредоточиться на моделировании бизнес-модели и разработке бизнес-логики.

Особенности фреймворка:

• Реактивность. Enode полностью реактивен, что является ключевым аспектом его высокой пропускной способности. В слое базы данных используется асинхронное управление, обеспечивая полную асинхронность по всей цепочке. Для операций, интенсивных в отношении ввода-вывода, интегрирована библиотека Kotlin Coroutine.
• Event Sourcing. События корневых агрегатов полностью сохраняются, записывая изменения состояния корневых агрегатов, позволяя отслеживать данные на стороне C и делая данные универсальными.
• Управление событиями. Бизнес-процессы основаны на управлении событиями, фокусируя разработку на создании и накоплении событий предметной области. Продвинутая система Saga обеспечивает поддержку управления процессами с помощью диспетчера процессов (Process Manager), поддерживая пользовательские операции, охватывающие несколько корневых агрегатов. Это позволяет избежать использования распределённых транзакций.
• CQRS. На основе архитектуры CQRS, enode решает проблемы высокой параллельной записи на стороне C QRS и обеспечивает последовательность и уникальность данных на обеих сторонах CQ. Поддерживаются два способа возврата результатов выполнения команд: Fire And Forget и Fire And Wait.
• Быстродействие и гибкость. Корневые агрегаты постоянно находятся в памяти (In-Memory Domain Model), что максимально избегает перестройки корневых агрегатов и позволяет полностью реализовать их в объектно-ориентированном подходе без необходимости балансировки между ORM. Обработка корневых агрегатов основана на концепции Actor, предоставляя оптимистичный параллельный контроль, отсутствие блокировок и повышая производительность записи через Group Commit Domain Event.

В архитектуре enode строго регламентирует, как разработчики должны писать код, требуя применения подхода DDD и строгого соблюдения принципов внутренней согласованности внутри агрегата и конечной согласованности между агрегатами.

Следуя принципам SOLID в дизайне, можно расширить или заменить следующие компоненты:

• Контейнер IoC, в настоящее время дружественный к SpringBoot.
• CommandBus, который требует только базовых возможностей очередей, в настоящее время совместим с Kafka, RocketMQ, Pulsar и AMQP.
• EventStore, совместимый с MySQL, PostgreSQL и MongoDB.
• ReplyService, требующий реализации модели связи «точка-точка» для уведомления о результатах обработки команд.

Ограничения использования:

• Одна команда может изменять только один корневой агрегат.
• Взаимодействие между агрегатами возможно только через доменные сообщения.
• Внутри агрегата требуется сильная согласованность.
• Между агрегатами требуется конечная согласованность.

Для получения дополнительной информации рекомендуется обратиться к документации и примерам использования.