Типы сообщений: сколько информации должно содержать сообщения?

Question

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

Основная идея/архитектура заключается в следующем:

• В заявке на производителя:
  • пользователь взаимодействует с некоторыми объектами (агрегатных корнями в том смысле, DDD), которые могут быть созданы/изменено/удалено
  • Основано на том, что происходит, события домена повышены (например: EntityXCreated, EntityYDeleted, EntityZTransferred и т. д. ... т.е.не только CRUD, но в основном)
  • Фальш событий транслируются/преобразуются в сообщения, которые мы посылаем к RabbitMQ бирже
• в RabbitMQ(мы используем RabbitMQ, но я считаю, что вопрос на самом деле технологии- независимые):
  • определит очередь для каждого потребляющего приложения
  • привязок соединить обмен на потребительские очереди (возможно, с фильтрацией сообщений)
• В потребляющего приложения (ов)
  • приложение потребляет и обрабатывать сообщения из своей очереди

На основе Enterprise Integration Patterns мы пытаемся определить канонический формат для наши опубликованные сообщения, и колеблются между 2 подходами:

1. Минималистские сообщения/событийно-магазин-иш: для каждого события, опубликованного в модели предметной области, генерирует сообщение, содержащее только те части совокупного корня, которые имеют отношение (например, когда обновление будет сделано только публиковать информацию об обновленном разделе совокупного корня, более или менее соответствующий процесс конечный пользователь проходит при помощи приложения)

   • Pros

     • маленький размер сообщения
     • очень специализированные типы сообщений
     • близко к "Доменные События"

   • Против

     • проблематично, если порядок доставки не гарантируется (т.е. что, если сообщение «Обновить» получено до создания сообщения?)
     • потребителям необходимо знать, какие типы сообщений следует подписывать (возможно, требуется знание большого списка/домена)
     • Что делать, если состояние потребителя и состояние производителя выходят из синхронизации?
     • как обрабатывать новый потребитель, который регистрирует в будущем, но не знание всех последних событий

2. Полностью содержащееся идемнотентный ишем сообщения: для каждого события, опубликованного Domain Model, генерирует сообщение, содержащее полный моментальный снимок Aggregate Root в этот момент времени, поэтому на самом деле обрабатывает только 2 вида сообщений «Создать или обновить» и «Удалить» (+ метаданные с более подробной информацией, если необходимо)

   • Pros

     • идемпотентных (декларативные сообщения о том, «это то, что правда, как, синхронизировать себя, однако вы можете»)
     • меньшего количества форматов сообщения для поддержания/ручку
     • позволяет постепенно исправлять ошибки синхронизации потребителей
     • потребитель автоматически обрабатывать новые доменные события до тех пор, как в результате сообщения следует модель канонического данные

   • Против

     • больше сообщение полезной нагрузки
     • менее чистый

бы вы рекомендовать подход над другим?

Есть ли другой подход, который мы должны рассмотреть?

Answer 1

Есть ли другой подход, который мы должны рассмотреть?

Вы могли бы также рассмотреть не утечки информации из службы, действующей в качестве technical authority для той части бизнеса

Что примерно означает, что ваши события несут идентификаторы, так что заинтересованные стороны могут знать о том, что субъект интерес изменился и может запросить полномочия для обновлений состояния.

для каждого события, опубликованного в модели предметной области, генерирует сообщение, которое содержит полный снимок совокупного корня в тот момент время

Это также имеет дополнительный Con, что любое изменение представление агрегата также подразумевает изменение схемы сообщений, которая является частью API. Таким образом, внутренние изменения в агрегатах начинают разрастаться через ваши границы обслуживания. Если совокупности, которые вы реализуете, представляют собой конкурентное преимущество для вашего бизнеса, вы, вероятно, захотите быстро адаптироваться; рябь добавляет трение, которое замедлит вашу способность к изменению.

Что делать, если состояние потребителя и состояние производителя выходят из синхронизации?

Насколько я могу судить, эта проблема указывает на ошибку конструкции. Если потребитель нуждается в состоянии, то есть в представлении, построенном из истории совокупности, тогда он должен получать этот вид от производителя, а не пытаться собрать его из коллекции наблюдаемых сообщений.

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

Опять же, отзывчивость к изменениям: если вы измените реализацию производителя, а потребители также пытаются собрать свою собственную копию истории, ваши изменения будут разбросаны по границам службы.