Adr*_*hum 21 domain-driven-design
如果我正在处理操作/事务类型的应用程序,我发现DDD很自然.但是,我总是以合理的方式处理报告类型的函数.
我正在讨论的报告不一定是报告生成,也是执行相对复杂查询的函数.(比如,给出交易者所做的所有订单的摘要,或显示具有特定股票的交易账户的账户摘要等).它们可以是与这些操作功能一起使用的一些查询或支持功能.
对于这样的函数,如果我们可以在SQL(或任何查询语言)中执行连接,获取我们感兴趣的列,并返回按摩结果集,这是很自然的.但是,使用DDD似乎不太顺利:我们需要一个额外的特殊存储库或者现有最相关的存储库返回一个特殊的"实体/值对象"(这是专门的结果集).这些特殊的"实体"实际上没有任何域意义.
如果我们想要使用有意义的域层,那么可能会从不同的存储库创建大量额外的查找,以及域或服务层中的大量聚合工作,这很容易导致可怕的性能下降.
我还想过为这类函数设置另一个"路径",它不会通过"DDD路径",有自己的方式从DB获取报告数据,组成显示结果.然而,它会使应用程序变得不必要地复杂化,更糟糕的是,我们提供了一个额外的路径,以便更习惯于传统的面向数据库开发的开发人员可能倾向于使用此路径,即使它不合适.
我认为这种情况很常见(通常一个大系统不会包含操作,还有报告和查询功能),我想知道人们如何处理它？
Den*_*aub 19
在DDD报告方面,在大多数情况下是一个单独的有界上下文和一个支持子域,其中域驱动设计将是过度的.记住DDD最重要的概念:将您的建模工作集中在核心域上,并使用最简单的解决方案实现其他所有功能.
我们最近开始使用 DDD 进行系统开发。我和你有同样的担忧，但最终选择了命令查询责任分离 (CQRS) [Fowler、Young、Dahan]。虽然它需要“数据库路径”来进行查询，但我完全不觉得直接对数据库执行命令（那些改变域状态的命令）变得诱人。分离非常清晰 - 命令通过域，查询直接到数据库。