Domain driven design DDD：如何处理；“视图”；物体

如果我们将订单用作聚合根（AR），将订单行用作非根聚合，那么您如何处理性能问题

我使用Order/OrderLine，因为它们是我们所有“无处不在的语言”中非常熟悉的一部分。所以请继续玩，我的“订单”在计算上很难存储，更难检索。当不使用DDD时，通常会将其“非规范化”为“视图”。使用DDD，可以创建OrderView域对象并使用OrderAR进行写入，使用OrderView AR进行读取吗？其他人是如何处理这种情况的

---

提前感谢您的建议。

我们通过创建简单的数据传输对象来处理此问题，这些对象通过底层SQL视图填充到应用程序处理程序中，该视图由来自底层域实体表的数据组成。我们发现这很有效，没有任何问题。我不会称之为CQRS，因为我们对命令和查询都使用相同的模型，但也许您可以称之为CQRS lite。我强烈建议您不要在域层中创建视图对象。它没有给你带来真正的价值，只是增加了一层复杂性。

我接受这一点，因为它至少是关于这个问题的一些建议/想法。我更希望听到它是如何与实际的域层绑定或绕过聚合对象的。尽管如此，还是要感谢您。将读取流与创建/写入流隔离和/或分离实际上是我需要的一个选项。然而，在我看来，这似乎与这个问题正交。也就是说，同样的问题也存在，尽管略有修改。由于这种分离为您提供了两种模型，读/查询模型是在DDD层建模的吗？如果是，同样的问题。如果没有，你会怎么做？“查询”是否直接与输出DTO的“存储库层”相对？在我看来，您的读取/查询模型不应该是域层的一部分。域层是关于在业务实体上强制执行不变量的。查询数据不符合我的标准。这就是为什么我通常把这种功能放在应用层的原因。查询不需要任何存储库，只需映射到DTO的简单ADO.NET数据读取器就足够了。无需对系统的读取端产生幻想。