существует идея хранилища событий и очереди сообщений, таких как Apache Kafka, и у вас есть события, поступающие из хранилища событий => Kafka Connect JDBC / Debezium CDC => Kafka
В сущности источников событий со вкусом DDD нет места для очередей сообщений как таковых.Одним из тактических шаблонов DDD является совокупный шаблон, который служит транзакционной границей.DDD не волнует, как сохраняется совокупное состояние, и обычно люди используют постоянство на основе состояния с реляционными базами данных или базами данных документов.При применении основанного на событиях постоянства нам нужно сохранять новые события как одну транзакцию в хранилище событий таким образом, чтобы мы могли получить эти события позже, чтобы восстановить агрегатное состояние.Таким образом, для поддержки поиска событий в стиле DDD хранилище должно иметь возможность индексировать события по совокупному идентификатору, и мы обычно ссылаемся на концепцию потока событий, где такой поток однозначно идентифицируется по совокупному идентификатору и где всесобытия хранятся по порядку, поэтому поток представляет собой единый агрегат.
Поскольку мы редко можем жить с базой данных, которая позволяет нам извлекать только одну сущность по ее идентификатору, нам нужно место, где мы можемспроектировать эти события в, чтобы мы могли иметь запрашиваемый магазинЭто то, что показано на диаграмме справа, в виде материализованных представлений.Чаще это называется read read , а модели там называются read-models .В таком магазине не нужно хранить снимки агрегатов.Напротив, модели чтения служат для представления состояния системы способом, который может напрямую использоваться UI / API, и часто он не совпадает с моделью предметной области как таковой.
Как уже упоминалосьв одном из ответов здесь типичный поток обработчика команд:
- Загрузка одного состояния агрегата по идентификатору путем чтения всех событий для этого агрегата.Уже требуется, чтобы хранилище событий поддерживало такую нагрузку, которую Кафка не может сделать.
- Вызовите модель домена (метод совокупного корня), чтобы выполнить какое-либо действие.
- Сохраните новые события вагрегатный поток, все или ничего.
Если вы сейчас начнете записывать события в хранилище и публиковать их где-то еще, вы получите проблему двухфазного принятия, которую трудно решить.Поэтому мы обычно предпочитаем использовать такие продукты, как EventStore , в котором есть возможность создать подписку на догонялки для всех записанных событий.Кафка это тоже поддерживает.Также полезно иметь возможность создавать новые индексы событий в магазине, связывая их с существующими событиями, особенно если у вас несколько систем, использующих один магазин.В EventStore это можно сделать с помощью внутренних проекций, вы также можете сделать это с потоками Кафки.
Я бы сказал, что вам действительно не нужна система обмена сообщениями между сторонами записи и чтения.Сторона записи должна позволять вам подписываться на канал событий, начиная с любой позиции в журнале событий, чтобы вы могли создавать свои модели чтения.
Однако Kafka работает только в системах, которые не используютагрегированный шаблон, потому что важно иметь возможность использовать события, а не снимок, как источник правды, хотя это, конечно, обсуждается.Я хотел бы взглянуть на возможность изменить способ, которым события изменяют состояние объекта (например, исправление ошибки), и когда вы используете события для восстановления состояния объекта, все будет в порядке, снимки останутся прежними, и выМне понадобится применить события исправления, чтобы исправить все снимки.
Лично я предпочитаю не быть тесно связанным с какой-либо инфраструктурой в моей модели домена.На самом деле, мои доменные модели не имеют никакой зависимости от инфраструктуры.Принося логику моментальных снимков в конструктор потоков Kafka, я был бы немедленно связан, и, с моей точки зрения, это не лучшее решение.