CQRS/EventStore - 建模和存储层次树
我想知道是否有人解决了使用 CQRS 和事件源（事件存储）与分层树的问题？
我们希望树中有 10 个或 1000 个节点和子节点，我担心带有事件源的 CQRS 是否不太适合解决这个问题。我还没有看过可以在事件存储方面使用的快照。
同样从 DDD 的角度来看，我是否会将其建模为模型中的复合设计模式，或者应该更能反映数据如何存储在我的读取模型（即本例中的 SQL Server）中。
I was wondering if anyone has tackled the issue of using CQRS and Event-Sourcing (Event-Store) with hierarchical trees?
We hope to have 10s of 1000s of nodes and childs in the tree and I am concerned whether CQRS with Event sourcing is not a good match for this problem. I have yet to look at snap shots which could be used on the event-store side.
Also from a DDD perspective, would I model it as a composite design pattern in my model or should it be more reflective of how the data is stored in my read model (i.e. SQL server in this case).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我倾向于同意这些评论，即 CQRS 对于您的应用程序确实没有优势。这是一个不太合适的地方。
为了回答您最初的问题，为了其他人的利益，我正在构建一个使用 CQRS 和 CQRS 的配置应用程序。 EventSourcing 具有基本上是分层树的结构。我正在使用图形数据库 [ Neo4J ] 来处理层次结构... [ 6 - 8 个不同级别的许多组]。
域反映了自下而上的关系，而 Neo4J 将处理两个方向。这样，事件存储可以非常快速地更新，并且对于那些需要遍历树/图[以创建可访问节点列表]的处理程序，他们可以使用图形数据库来实现这一点。
CQRS 实际上非常适合这个应用程序，而且我实际上相当惊讶的是，我的方法完全没有受到阻碍。每个人似乎都同意，这是比更传统的 CRUD 方法更好的替代方案。
我要替换的系统将这些关系存储在 SQL 中，这就是存在巨大性能问题的地方！这应该会好得多。
I tend to agree with the comments, that there really isn't an advantage to CQRS for your application. It's a poor fit.
To answer your original question for someone else's benefit, I am building an application for Provisioning that uses CQRS & EventSourcing that has what are basically hierarchical trees. I am using a graphing database [ Neo4J ] to handle the hierarchy... [ Lots of groups at 6 - 8 different levels ].
The Domain reflects the relationships bottom up, while Neo4J will handle both direction. That way the eventStore can update very quickly, and for those handlers which need to traverse the tree/graph [ in order to create lists of accessible nodes ], they can use the Graphing Database for that.
CQRS is actually a pretty good fit for this application, and I was actually fairly surprised that there was no push back at all to my approach with this. Everyone seemed to agree that this was a much better alternative to a more traditional CRUD approach.
The system I am replacing stores these relationships in SQL, and that's where are having HUGE performance issues! This should be dramatically better.