使用 CQRS 进行多对多关系的替代方案
我们如何使用 CQRS/DDD 建模经典的多对多关系？
我知道 DDD 和 CQRS 实现和解决方案往往是特定于领域的，因此可能很难对这个问题给出通用答案。
但是，假设我们在Book 和Author 之间有熟悉的关系。这是一个经典的多对多关系。
对我来说，书籍和作者似乎是两个不同的实体，每个实体都属于自己的聚合根，这似乎是最自然的>。因此，明确地建模它们之间的多对多关系并不是正确的方法。
我们如何为 AddBookCommand 建模？我们希望能够将一本书添加到我们的图书馆，并以某种方式声明特定的作者写了这本书。我们如何建模（并维持）这样的关系？
书籍和作者似乎都不适合值对象...
How do we model classic many-to-many relationships with CQRS/DDD?
I know that both DDD and CQRS implementations and solutions tend to be domain-specific, so it may be difficult to come up with a general answer to this question.
However, let's assume we have the familiar relationship between Book and Author. This is a classic many-to-many relationship.
To me, it seems most natural that Book and Author are two different Entities that each belong in their own Aggregate Root. Thus, explicitly modeling the many-to-many relationship between them is not the way to go.
How do we model an AddBookCommand? We want to be able to add a book to our library, and also somehow state that a particular Author wrote this Book. How do we model (and persist) such a relationship?
Neither Book nor Author seem like good candidates for Value Objects...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
假设两者都是聚合，请在添加新书时将所需的任何作者数据复制到 Book 聚合中，以便任何后续命令都有足够的作者数据可以使用。现在，如果 Author 聚合需要有关作者所写书籍的信息，那么它可以“订阅”NewBookAdded 事件（从技术上讲，您可以将 RegisterAsAuthorOfBook 命令发送到 Author 聚合，作为 NewBookAdded 事件的结果）。我认为人们也可以以相反的方式对此进行建模，但我对图书作者领域并不那么熟悉。
最重要的是，您并没有真正存储多对多，因为它们无法扩展。您必须开始将它们（聚合）视为相互发送消息。更大的问题是什么需要保持一致以及在什么时间点需要保持一致。我们是否关心作者没有立即反映添加了一本新书（她/他是作者）的事实？作者是否希望对他/她所写的书强制执行任何不变量（反之亦然）？
另一件事是停止以数据为导向，而更加以行为为导向。书籍和作者聚合的行为是什么？这将告诉您在哪个点需要什么数据以及如何对其进行建模。
http://pastie.org/1220582 首次尝试图书聚合。
Supposing that both are aggregates, copy whatever author data you need into the Book aggregate upon adding the new book so that any subsequent commands have enough author data to work with. Now if the Author aggregate needs information about the books written by the author, then it could "subscribe" to the NewBookAdded event (technically you could send a RegisterAsAuthorOfBook command to the Author aggregate as a result of the NewBookAdded event). I presume one could model this the other way around as well, but I'm not that intimate with the Book Author domain.
Bottom line is that you don't really store many-to-many because they don't scale. You have to start thinking of them (aggregates) as sending messages to each other. The bigger question is what needs to be consistent and at what point in time does it need to be consistent. Do we care that the Author does not instantaneously reflect the fact a new Book has been added, of which she/he's the author? Are there any invariants that Author wants to enforce with regard to the books he/she has written (and vice versa)?
Another thing is to stop being data oriented and more behavior oriented. What's the behavior of the Book and Author aggregate? This will tell what data is required at which point and how it should be modelled.
http://pastie.org/1220582 for a first stab at the Book aggregate.