Источник событий, CQRS с Axon Server / Framework - Источник событий - хорошая идея?

Question

Этот вопрос очень слабо связан с Axon Server / Framework, поскольку я изучаю его специально, изучая и пытаясь научиться создавать микросервисы. Поскольку сложно узнать обо всех архитектурных шаблонах без реального практического опыта (и трудно получить практический опыт без большого приложения, с которым можно на самом деле тестировать / строить), я много теоретизирую здесь (мои вопросы могут просто будь глупым, извини, я еще учусь).

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

Учтите это:

Я создаю потоковую платформу, подобную Twitch. Существуют основные c, очевидные услуги, такие как служба поддержки клиентов с данными своего профиля, служба заказов (для подписок, пожертвований) и т. Д. c.

Но есть и другие сервисы, такие как система чата. Гипотетически, я чувствую, что использование системы чата для событий было бы весьма полезно, потому что у вас были бы встроенные временные метки для воспроизведения чата, если зрители смотрят VOD. Однако я также чувствую, что не следует смешивать события для системы чата с хранилищем событий, которое занимается транзакциями; Это две совершенно разные системы, и просто хранить каждое событие из каждой службы в одном хранилище событий ... Monolithi c?

Мне все еще неясно, каковы лучшие практики. Все примеры и примеры из докладов всегда показывают очень простые c системы с типичными агрегатами Customer, Order, Item и не go подробно описывают, как это простое приложение вырастет в крупную службу, такую ​​как Twitch.

Итак, мои вопросы таковы:

1) Должны ли вы использовать источник событий для всего приложения или вы можете выбрать, какие из них будут источником событий, а не?

2) Имеет ли Axon Server поддерживать два разных хранилища событий, например, один для системы чата и один для других служб? Буду ли я в этом случае запускать два разных экземпляра Axon Server? Если у приложения когда-либо будет два разных хранилища событий, или я помещаю каждое событие в одно хранилище событий, независимо от того, отправляет ли что-то вроде системы чата куда больше событий, чем что-либо еще (будет ли хорошая идея получить систему чатов, учитывая сценарий использования, который я указал, где зрители могли бы «воспроизвести» журнал чата?)?

3) Сама идея единого хранилища событий, являющегося единственным источником истины, кажется монолитной c. Я ошибаюсь, думая об этом, и если нет, как можно обойти это, если у меня действительно большое приложение?

Answer 1

1) Если вы используете источник событий для всего приложения или вы можете выбрать, какие из них использовать, а какие нет?

Вы, вероятно, не должны: Если я буду рассматривать ваши приложения как модели субдоменов (ограниченные контексты), тогда я смогу расставить приоритеты этих субдоменов как Core, Supporting и Generi c. Я хотел бы использовать шаблон событий на Core (ключевой отличительный признак для бизнеса) и, возможно, поддержку поддоменов, но я бы не стал использовать событийный поднабор на доменах Generi c. Субдомены Generi c, как правило, являются тем, что вы передаете на аутсорсинг или покупаете, и они не повышают ценность вашего бизнеса.

2) Поддерживает ли Axon Server два разных хранилища событий, например одно для система чата и одна для других служб? Буду ли я в этом случае запускать два разных экземпляра Axon Server? ...

Я уже упоминал шаблон ограниченных контекстов. Axon Server позволяет вам использовать этот шаблон. Axon Server Standard Edition имеет только один контекст (называемый default). В Axon Server Enterprise Edition можно настроить несколько контекстов, а затем подключить приложения для их использования (в сценарии на основе ролей). Каждый контекст физически связан со своим собственным хранилищем / хранилищем событий (один контекст = одно хранилище).

Я бы не отказался какое-то время хранить события в одном контексте / хранилище событий по умолчанию (используя Axon Server CE). Особенность событийного аутсорсинга заключается в том, что вы отделяете свои данные от поведения, и в будущем должно быть легко перенести ваше хранилище событий в несколько хранилищ событий. Сейчас я бы сосредоточился на дизайне и поведении ваших приложений, а также на последнем. Это эволюционный подход!

3) Вся идея единого хранилища событий, являющегося единственным источником истины, кажется монолитной c. Я ошибаюсь, думая об этом, и если нет, как можно обойти это, если у меня действительно большое приложение?

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