Domain driven design CQRS&；DDD-使用cqrs读取模型验证域模型业务规则

我是DDD和CQRS模式的新手，我想听听您对如何验证域实体的看法。 我将使用常见的示例Order->OrderLine，其中Order是AR

聚合中业务规则的验证是通过AR进行的，以确保一致性。 如何验证需要订单集合之外的数据的业务规则

---

我也在使用CQRS方法，我认为使用ReadModel获取验证业务规则所需的数据并不是一个坏选择……您认为如何？

是的，使用read模型进行命令验证。我称之为“命令上下文”——世界的当前状态，根据它命令可能有效或无效。在CQRS中，世界的当前状态在您的读取模型中表示。用户正在根据它做出决策，应该发出什么命令

---

您还可以考虑各种方法来引导用户决策，这样他就不会发出无效的命令（如果用户名不是唯一的，事先警告，等等）。因此，我对表示系统当前状态的ReadModel没有100%的信心。当您想要分发和复制您的ReadModels时，情况就更糟了

我只想使用ReadModel来限制发送到应用程序的无效命令的数量

在我看来，您应该开始考虑域服务，它可以用来封装位于单个聚合/实体/值对象边界之外的域逻辑

---

正如David在这里指出的，Jimmy Bogard有一个定义

验证通常意味着输入，因此它会发生在命令端（写端）。您将在read模型上执行什么验证？实际上，域服务在这里似乎是合适的；问题是：还需要哪些其他数据？我假设是存储在另一个聚合中的数据？是的，存储在另一个聚合中的数据，例如，与AR没有任何关联的数据。域服务似乎是一种很好的方法。对域服务的需求是缺乏聚合根的强烈迹象。正如穆特斯指出的，读取模型最终是一致的。这意味着这是过去某个时刻的世界状况。域是唯一真正的“当前世界状态”。如果你试图支持跨AR一致性，那么你就有点放弃了可伸缩性——这意味着，首先使用CQR的理由少了一个。是的，如果实现是纯CQR，并且使用两个不同的数据库，一个用于写入，另一个用于读取，并通过域事件进行更新，则读取模型不是查询一致/最新数据的好方法@driushkin说的是完全正确的；您可以使用read模型进行命令验证（即降低命令失败的可能性），但我不认为这是问题所在。问题似乎与域业务规则不变量有关。这里涉及的数据必须是“真相的来源”。我认为这种混淆来自于作者对“验证”一词的使用。