Инфраструктура для Event Sourcing
Chronacta — сервер-хранилище событий, который вы разворачиваете у себя. Он предоставляет потоки с версиями и API для записи, чтения, подписок, управления схемами и работы с проекциями. Модель предметной области остаётся под управлением приложения.
Что предоставляет Chronacta
Приложению на Event Sourcing нужно не только место для записи JSON. Нужны упорядоченные потоки, проверка конкурентной записи, надёжное чтение и сохранение позиции обработки потребителей.
Chronacta предоставляет эти механизмы через сетевой API. Приложение определяет, какие события создавать; Chronacta сохраняет их и предоставляет для последующей обработки.
Потоки, версии и схемы
Каждый поток содержит упорядоченную последовательность событий и имеет версию. Проверка ожидаемой версии отклоняет запись, основанную на устаревшем состоянии потока. Ключ идемпотентности позволяет повторить тот же запрос без добавления дубликата в пределах контракта идемпотентности API.
Глобальные позиции позволяют читать события из разных потоков. Подписки доставляют события потребителям, а проекции строят модели чтения. Реестр схем проверяет содержимое событий по зарегистрированным определениям JSON Schema.
В приложении на DDD с Event Sourcing поток обычно хранит события одного экземпляра агрегата. Агрегат обеспечивает соблюдение инвариантов, а версия потока помогает не допустить записи параллельных решений, принятых на устаревшем состоянии.
Обработка команд и запросов
Обработчик команды загружает агрегат через репозиторий, вызывает его поведение и сохраняет полученные события. Репозиторий может восстанавливать агрегат из потока и добавлять новые события с прочитанной версией.
В архитектуре CQRS обработчики запросов используют модели чтения, подготовленные под их задачи. Проекции заполняют эти модели, обрабатывая события. Модели чтения могут находиться в памяти приложения, реляционной базе или другом подходящем хранилище.
Проекция — это преобразование, а модель чтения — его результат. Изменение логики проекции может потребовать пересборки модели чтения. Оно не меняет ранее записанные события и не исправляет автоматически ошибки обработки команд.
Границы продукта
Chronacta не выполняет произвольные реляционные запросы. Для соединения таблиц, поиска и аналитики по производным данным используйте подходящую базу данных.
Chronacta не является прямой заменой Kafka или NATS. Хранилище событий и брокер сообщений могут дополнять друг друга в одной архитектуре.
Chronacta не реализует ваши агрегаты, обработчики команд и инварианты предметной области. Это инфраструктурный компонент, а не каркас приложения.
Вы разворачиваете и обслуживаете сервер. Chronacta предназначен для одного узла; Enterprise добавляет возможности высокой доступности и дополнительные средства эксплуатации.
Интеграция между контекстами
Явно определяйте владельцев потоков и контрактов событий. Ограниченный контекст отвечает за свою модель предметной области; другим контекстам не следует зависеть от каждого её внутреннего события.
Подписчик может преобразовывать события домена в интеграционные события для другого ограниченного контекста. Postgres может хранить модели чтения, а NATS или Kafka — распространять интеграционные события, когда нужен внешний транспорт.
Длительные процессы координируйте в компонентах приложения, например в менеджерах процессов. Chronacta хранит и доставляет события, но не определяет ход бизнес-процесса.
От разработки к эксплуатации
Начните с одного агрегата, обработчика команды и проекции. Проверьте успешную запись, конфликты версий, повторные запросы и пересборку модели чтения.
Перед вводом в эксплуатацию определите процедуры резервного копирования и восстановления, возобновления работы потребителей, контроля доступа, мониторинга и изменения схем событий.
Выбирайте Chronacta или Enterprise с учётом измеренной нагрузки и требований к доступности, интеграции с системой аутентификации, восстановлению и администрированию.