如果我正在处理操作/事务类型的应用程序，我发现 DDD 是很自然的。然而，我总是坚持以一种合理的方式来处理报告类型的功能。
我所说的报告不限于报告生成，还包括执行相对复杂查询的功能。 (例如，提供交易者所做的所有订单的摘要，或显示具有某些股票的交易账户的账户摘要等)。它们可以只是一些与这些操作功能一起使用的查询或支持功能。
对于这样的函数，如果我们可以在 SQL(或任何查询语言)中执行连接，获取我们感兴趣的列，并返回按摩后的结果集，这是很自然的。然而，DDD 似乎不太适合这种方式:我们需要一个额外的特殊存储库，或者让现有最相关的存储库返回一个特殊的“实体/值对象”(这是专门的结果集)。这些特殊的“实体”实际上没有任何领域意义。
如果我们想利用有意义的领域层，那可能会从不同的存储库中产生大量额外的查找，再加上领域或服务层的大量聚合工作，这很容易导致可怕的性能下降。
我也想过为这类函数设置另一个“路径”，它不通过“DDD路径”，有自己的方式从数据库获取报告数据，组合结果进行显示。但是这会让应用程序变得不必要的复杂，更糟糕的是，我们提供了一个额外的路径，以便更习惯于传统面向 DB 开发的开发人员可能会倾向于使用该路径，即使它并不合适。
我觉得这种情况挺普遍的(一般大系统不会有操作也有报表查询功能)，想知道大家是怎么处理的？
最佳答案
我们最近开始使用 DDD 进行系统开发。我和你有同样的担忧，但最终还是选择了命令查询职责分离 (CQRS) [Fowler, Young, Dahan]。虽然查询需要“数据库路径”，但我一点也不觉得直接对数据库进行命令(那些改变域状态的命令)变得很有吸引力。分离非常明确 - 命令通过域，查询直接到数据库。
关于domain-driven-design - 领域驱动设计如何处理报告？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11554231/