如果我正在开发运行/交易类型的应用程序,我发现DDD是自然的.不过我总是以合理的方式处理报告类型的功能.
我正在谈论的报告不一定是报告生成,而且也是执行比较复杂的查询的功能. (如,给出交易者所做的所有订单的摘要,或显示具有某种股票的交易账户的帐户摘要等).它们可以只是一些与这些操作功能一起使用的查询或支持功能.
对于这样的功能,如果我们可以执行SQL(或任何查询语言)的连接,获取我们感兴趣的列,并返回按摩结果集,这是很自然的.然而,DDD似乎并没有那么好:我们需要一个额外的特殊的存储库,或者现有最相关的存储库返回一个特殊的“实体/值对象”(这是专门的结果集).这些特殊的“实体”实际上没有任何领域的意义.
如果我们想利用有意义的域层,那么可能会从不同的存储库中创建大量额外的查找,还有很多在域或服务层中的聚合工作,这很容易导致可怕的性能下降.
我也想到对于这种功能有另一个“路径”,这不是通过“DDD路径”,有自己的方式从DB获取报告数据,组合显示结果.然而,这将使应用程序不必要地复杂化,更糟糕的是,我们提供了一个额外的路径,使得更适用于传统的面向DB的开发的开发人员可能倾向于使用此路径,即使不合适.
我认为这种情况是很常见的(通常一个大系统不会包含操作,但也不包括报告和查询功能),我想知道人们如何处理它?
解决方法
我们最近使用DDD进行系统开发.我和你的关系一样,但最终定居于命令查询责任分离(CQRS)[Fowler,Young,Dahan].虽然需要“db路径”用于查询,但我根本不觉得直接对DB进行命令(那些改变域状态)变得诱人.分离非常清楚 – 命令通过域,查询直接转到数据库.
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。