Сколько хранилищ событий мы должны использовать в нескольких ограниченных контекстах?

Question

В настоящее время я читаю о DDD, и мне не удалось найти ответ на этот вопрос. Если у нас есть большое приложение с несколькими ограниченными контекстами, то, насколько я знаю, мы должны реализовать каждый BC, как это было отдельное приложение. Таким образом, логично прийти к выводу, что каждый BC имеет свой собственный пользовательский интерфейс и хранилище событий. Ранее я думал, что у нас есть только одно хранилище событий, потому что, согласно некоторым статьям, оно является единственным источником правды (о CQRS). Единственная проблема с этими утверждениями в том, что у них нет контекста. Так является ли хранение событий единственным источником правды в одном ограниченном контексте или во всем приложении?

Answer 1

  "Is an ES the single source of truth in a bounded context or in entire application?" 

Я предполагаю, что вы имели в виду систему, потому что Bounded Context - это приложение в самом простом объяснении.

 "If we have a large application with multiple bounded contexts"

Вы не можете иметь несколько ограниченных контекстов в одной и той же модели. Ограниченный контекст ограничивает модель. Таким образом, вы должны изменить срок bounded context за subdomain и это было бы правильно.

Во всяком случае, отвечая на ваш вопрос. Это зависит.

Единое хранилище событий для всей системы

Pros

• Одно место для управления
• Связанные события легко увидеть по CorrelationID
• В некоторых программах нет необходимости в обнаружении сервисов. Все сервисы (приложения) могут интегрироваться через одну ES (я говорю о настоящей ES, а не о хранении данных).
• Требуется меньше процессора / памяти

Cons

• Единственная точка отказа (конечно, вы можете масштабировать ее, чтобы избежать такой ситуации)
• Вы соединяете сервисы вместе (нарушая правила микросервиса)
• Обязан не менять ES в течение срока службы системы

Один магазин событий на приложение

Pros

• Нет единой точки отказа
• Развернуто с приложением
• Нет связи между сервисами. Больше автономии
• Если приложение будет отключено, ES может быть отключен с ним
• Новые сервисы могут работать с новыми версиями или даже с разной ES

Cons

• Дополнительные базы данных, чтобы заботиться и контролировать
• Больше процессора / оперативной памяти потребляется
• Сложнее управлять идентификаторами корреляции, потому что они распределены между несколькими ES
• Требуется некоторое обнаружение службы. Для подписки на несколько ES или необходимости в дополнительной очереди сообщений