DDD CQRS中聚合的读取模型

Question

在CQRS ES和DDD中，聚合中的小读模型从其他聚合或有界上下文中获取数据是件好事吗？

例如，在订单验证（订单聚合）中，有一个业务规则，该规则仅在未标记客户时验证订单。标志信息通过同步域事件放入读取模型（特定于聚合）。

你怎么看？

Answer 1

它是可行的，但不是以读模型的形式，而是聚合中的值对象（因为我们在写端）。

如果在订单中已经有一个客户ID，只需用它和一个标记了的成员组成一个VO即可。

当然，这仍然容易出现跨聚合通信的所有问题，因为数据来自Customer<代码>订单必须与其客户的标记状态保持同步，这可能需要大量工作。

在任何情况下，您都应该首先与您的领域专家确定立即一致性是否是绝对要求（在这种情况下，您必须以某种方式在事务中包装客户订单），或者在强制执行该不变量时，您是否能够在标记的新鲜度方面承受小的延迟。如果是后者，您可以选择复制顺序中标记的聚合或@VoiceOfUnreason提供的第一个选项——主要区别可能是，如果数据在聚合中，如果您在多个场合需要它，您将在域级别免费获得它，而不是在应用程序级别复制多个用例/命令处理程序中的签入。

Answer 2

在聚合中使用小型读取模型从其他聚合或有界上下文中获取数据是件好事吗？

这并不理想。由于聚合的性质，它们不善于执行涉及自身之外状态的一致性。

这通常意味着当两个聚合产生不可接受的状态时，业务将需要某种方式来响应。

在对聚合运行placeOrder命令之前，您还可以选择检查标志。对标志的检查可以在命令处理程序中完成，也可以在客户机中完成——基本上，您需要在将命令传递给聚合之前“验证”命令是否应该成功。

这就是说，如果在处理命令时尝试参考读取模型是至关重要的，那么一种方法就是使用“域服务”；将服务提供者作为命令的一部分传递给聚合，并让接口抽象掉运行查询需要查看聚合外部的事实。

这为您提供了一些保持聚合可测试性所需的解耦。