与 CQRS 的多对多关系的替代方案 [英] Alternatives to many-to-many relationships with CQRS

问题描述

我们如何使用 CQRS/DDD 为经典的多对多关系建模?

How do we model classic many-to-many relationships with CQRS/DDD?

我知道 DDD 和 CQRS 的实现和解决方案往往是特定于领域的，因此可能很难对这个问题给出一个通用的答案.

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.

但是，假设我们在 Book 和 Author 之间有熟悉的关系.这是一个经典的多对多关系.

However, let's assume we have the familiar relationship between Book and Author. This is a classic many-to-many relationship.

对我来说，Book 和 Author 是两个不同的实体，每个都属于自己的聚合根，这似乎是最自然的.因此，对它们之间的多对多关系进行显式建模并不是可行的方法.

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.

我们如何为 AddBookCommand 建模?我们希望能够将一本书添加到我们的图书馆，并以某种方式声明特定的作者编写了这本书.我们如何建模(并保持)这种关系?

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...

推荐答案

假设两者都是聚合，在添加新书时将你需要的任何作者数据复制到 Book 聚合中，以便任何后续命令都有足够的作者数据来处理.现在，如果 Author 聚合需要有关作者所写书籍的信息，那么它可以订阅"NewBookAdded 事件(从技术上讲，作为 NewBookAdded 事件的结果，您可以向 Author 聚合发送 RegisterAsAuthorOfBook 命令).我想人们也可以用另一种方式对此进行建模，但我对 Book Author 域并不那么熟悉.

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)?

另一件事是停止以数据为导向，而更以行为为导向.Book 和 Author 聚合的行为是什么?这将说明在哪个点需要哪些数据以及应该如何对其进行建模.

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，第一次尝试图书聚合.

http://pastie.org/1220582 for a first stab at the Book aggregate.

这篇关于与 CQRS 的多对多关系的替代方案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！