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

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


event-sourcing domain-driven-design bounded-contexts
person inf3rno    schedule 08.01.2016    source источник
comment
Некоторое время назад я задавал аналогичный вопрос в почтовой группе DDD и, к сожалению, не получил убедительного ответа. Одним из недостатков использования нескольких хранилищ событий является усложнение воспроизведения событий из всех этих хранилищ. Вы бы запускали их параллельно? последовательно? Как бы вы тем временем поставили в очередь входящие события? много сложных задач и так мало материала для принятия решений :)   -  person Songo    schedule 17.01.2016
comment
@Songo У меня сложилось впечатление, что с несколькими хранилищами лучше. По крайней мере, каждый бк должен быть чем-то вроде отдельного приложения. Таким образом, воспроизведение должно выполняться на уровне bc, а не для каждого отдельного bc. По крайней мере, это кажется логичным, но я тоже не уверен. Попробую спросить у кого-нибудь с опытом DDD, может, ответит.   -  person inf3rno    schedule 18.01.2016
comment
@Songo Я разговаривал с парнем, он предпочитает одно хранилище событий и использует несколько хранилищ событий только в том случае, если есть причина, например, разные команды работают над разными bc-s, и у них нет доступа к базам данных друг друга, или быстрее использовать несколько хранилищ событий и т. д. Так что здесь нет эмпирического правила, я думаю, что могу принять ответ Дарисса.   -  person inf3rno    schedule 19.01.2016
comment
Прохладный! Какой магазин событий он использует? Насколько я знаю, ни одно хранилище событий не поддерживает эту функциональность из коробки. Я надеялся, что смогу найти хранилище событий, которое поддерживает порционирование (т. е. несколько физических хранилищ, но действует как одно логическое) так же, как вы разбиваете базу данных.   -  person Songo    schedule 19.01.2016
comment
@Songo Почему это так важно? Я имею в виду, что в текущем bc вам нужны только связанные события. События других bc-ов действуют как команды (ака. сага), которые могут вызывать различные события в вашем текущем bc.   -  person inf3rno    schedule 19.01.2016

Ответы (1)


arrow_upward
5
arrow_downward 

  "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, и это будет правильно.

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

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

Плюсы

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

Минусы

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

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

Плюсы

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

Минусы

  • Дополнительные базы данных, о которых нужно заботиться и отслеживать
  • Больше процессора/ОЗУ потребляется
  • Сложнее управлять идентификаторами корреляции, поскольку они разделены между несколькими ES.
  • Требуется некоторое обнаружение службы. Для подписки на несколько ES или необходимости в дополнительной очереди сообщений
person Dariss    schedule 09.01.2016
comment
Хм интересно, я не знал, что можно выбирать, я думал, что есть строгое правило. - person inf3rno; 09.01.2016
comment
Почему вы предполагаете архитектуру микросервисов? Ваш ответ, кажется, сосредоточен на микросервисах, хотя вопрос не имеет к этому никакого отношения. Или я неправильно понимаю ваш ответ? - person theDmi; 11.01.2016
comment
Мы говорим о EventStore в ограниченном контексте. Мои ответы основаны на архитектуре микросервисов, вы прямо здесь. Но как вы его применяете: как микросервисную архитектуру, SOA-архитектуру или просто безымянную распределенную архитектуру — не имеет значения. Если вы идете с монолитным приложением, и вы не касаетесь множественных ES, потому что это не имеет смысла. - person Dariss; 11.01.2016