我们如何使用 CQRS/DDD 建模经典的多对多关系？
我知道 DDD 和 CQRS 的实施和解决方案往往是特定于领域的，因此可能很难对这个问题提出一个通用的答案。
但是，假设我们在 Book 和 Author 之间有熟悉的关系。这是经典的多对多关系。
对我来说，Book 和 Author 是两个不同的 实体 似乎很自然，每个实体都属于自己的 聚合根。因此，显式建模它们之间的多对多关系并不是可行的方法。
我们如何为 AddBookCommand 建模？我们希望能够将一本书添加到我们的图书馆，并以某种方式声明特定的作者写了这本书。我们如何建模（并保持）这种关系？
Book 和 Author 似乎都不适合 Value Objects...
【问题讨论】：
标签： architecture domain-driven-design cqrs dddd
假设两者都是聚合，在添加新书时将您需要的任何作者数据复制到 Book 聚合中，以便任何后续命令都有足够的作者数据来处理。现在，如果 Author 聚合需要有关作者所写书籍的信息，那么它可以“订阅” NewBookAdded 事件（从技术上讲，您可以将 RegisterAsAuthorOfBook 命令发送到 Author 聚合作为 NewBookAdded 事件的结果）。我想人们也可以反过来建模，但我对 Book Author 域并不熟悉。
底线是您并没有真正存储多对多，因为它们无法扩展。您必须开始将它们（聚合）视为相互发送消息。更大的问题是什么需要保持一致以及在什么时间点需要保持一致。我们是否关心作者不会立即反映添加了新书的事实，她/他是其中的作者？作者是否希望对他/她所写的书籍强制执行任何不变量（反之亦然）？
另一件事是停止面向数据和更多面向行为。 Book 和 Author 聚合的行为是什么？这将说明在什么时候需要什么数据以及应该如何建模。
http://pastie.org/1220582 首次尝试 Book 聚合。
【讨论】：