CQRS / EventStore - Моделирование и хранение иерархического дерева

Question

Мне было интересно, занимался ли кто-нибудь вопросом использования CQRS и Event-Sourcing (Event-Store) с иерархическими деревьями?

Мы надеемся, что в дереве будут десятки из 1000 узлов и дочерних элементов, и меня беспокоит, не подходит ли CQRS с источником событий для этой проблемы. Мне еще предстоит взглянуть на снимки, которые можно использовать на стороне магазина событий.

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

Answer 1

Я склонен согласиться с комментариями, что у CQRS нет никаких преимуществ для вашего приложения.Это плохо подходит.

Чтобы ответить на ваш первоначальный вопрос для чьей-либо выгоды, я создаю приложение для обеспечения, которое использует CQRS и EventSourcing, которые имеют в основном иерархические деревья.Я использую графическую базу данных [Neo4J] для управления иерархией ... [Много групп на 6 - 8 различных уровнях].

Домен отражает отношения снизу вверх, тогда как Neo4J будет обрабатывать оба направления.Таким образом, EventStore может обновляться очень быстро, и для тех обработчиков, которым необходимо пройти по дереву / графику [для создания списков доступных узлов], они могут использовать для этого базу данных графов.

CQRS на самом делеЭто очень хорошо подходит для этого приложения, и я был довольно удивлен, что в моем подходе к этому не было никакого отступления.Казалось, все согласны с тем, что это гораздо лучшая альтернатива более традиционному подходу CRUD.

Система, которую я заменяю, сохраняет эти отношения в SQL, и именно здесь возникают ОГРОМНЫЕ проблемы с производительностью!Это должно быть значительно лучше.