CQRS требует наличия двух отдельных моделей, модели команд и модели запросов, в одной «сфере приложения» / контексте, поэтому вы будете
То, как обе модели представлены с точки зрения хранилища, полностью зависит от деталей реализации, в то время как вы полагаете, что вы будете использовать обычные СУБД с / без индексированных таблиц.
Вопрос синхронизации снова совершенно другой, и у вас снова есть несколько вариантов. В его нынешнем виде я довольно хорошо понимаю Axon, поэтому позвольте мне разбить то, что было выбрано с его точки зрения:
Хранение модели команд: Вы можете выбрать сохранение модели команд. как есть или через Event Sourcing. Таким образом, первое решение, которое Аксон предпочитает называть «подходом с сохранением состояния», означает, что у вас будет относительно простой формат сущности модели команд. С другой стороны, решение Event Sourcing обеспечивает использование хранилища событий. После извлечения из Командной модели Repository будет создан пустой экземпляр Командной модели, и все события, которые опубликовал , будут воспроизведены для пустой версии. Это эффективно воссоздает командную модель каждый раз, когда вы ее извлекаете.
Хранение модели запроса: Как вы могли заметить, Axon здесь вообще не делает выбор. Пользователь сам решает, какой механизм хранения он использует.
Синхронизация модели: Как упоминалось ранее, существует несколько возможных вариантов. Опция, выбранная Аксоном, - это архитектура, управляемая событиями. Таким образом, командная модель получает команду (запрос о намерении выполнить некоторую операцию) и принимает решение по запросу. Как результат, событие будет опубликовано, эффективно «актуализируя» решение. Затем это событие распространяется асинхронно каждому заинтересованному компоненту. Эти «компоненты» являются, например, классами, обновляющими модели запросов, которые вы получили в своем приложении.
Надеюсь, что это справедливо для вопросов, которые у вас могут возникнуть, Даршу!