如果我正在开发运行/交易类型的应用程序,我发现DDD是自然的.不过我总是以合理的方式处理报告类型的功能.
我正在谈论的报告不一定是报告生成,而且也是执行比较复杂的查询的功能. (如,给出交易者所做的所有订单的摘要,或显示具有某种股票的交易账户的帐户摘要等).它们可以只是一些与这些操作功能一起使用的查询或支持功能.
对于这样的功能,如果我们可以执行sql(或任何查询语言)的连接,获取我们感兴趣的列,并返回按摩结果集,这是很自然的.然而,DDD似乎并没有那么好:我们需要一个额外的特殊的存储库,或者现有最相关的存储库返回一个特殊的“实体/值对象”(这是专门的结果集).这些特殊的“实体”实际上没有任何领域的意义.
如果我们想利用有意义的域层,那么可能会从不同的存储库中创建大量额外的查找,还有很多在域或服务层中的聚合工作,这很容易导致可怕的性能下降.
我也想到对于这种功能有另一个“路径”,这不是通过“DDD路径”,有自己的方式从DB获取报告数据,组合显示结果.然而,这将使应用程序不必要地复杂化,更糟糕的是,我们提供了一个额外的路径,使得更适用于传统的面向DB的开发的开发人员可能倾向于使用此路径,即使不合适.