考虑典型的 order/orderLine DDD 实施。如何获得产品总销售额？答案

【问题标题】：Accounting for a typical order/orderLine DDD implementation . How to get total product sales?考虑典型的 order/orderLine DDD 实施。如何获得产品总销售额？
【发布时间】：2014-02-20 16:21:24
【问题描述】：

假设订单的典型模型：

订单（聚合根）{OrderLine} OrderLine (entityInsideOrderAR) {产品;数量} 产品（聚合根）{name}

这是出于会计目的的适当设计吗？我的意思是，calculateTotalProductSales() 应该在哪里？引用应该是非循环的，所以如果产品应该有一个 OrderCollection 这将不是一个好的设计。即使对于 Product 的特殊聚合子项， ProductHistory 也应该引用 Order 并且再次加载一个对象多次（循环引用）。

对于这种情况，什么是好的设计？基本上我需要根据产品销售额进行一些计算（countTotalSalesForProduct（），calculateTotalSalesForProduct（）等......一些简单的会计计算）。

附： : 将 OrderLine 提升一级并使其成为自己的 AR 是否是个好主意？

【问题讨论】：

标签： oop architecture domain-driven-design

【解决方案1】：

可以将会计功能拆分为单独的有界上下文。可以在不破坏现有订购环境的情况下开发一套专属模型。此外，现实中有很多订单信息对于会计领域来说是不必要的（例如送货地址、备注等）。报告和统计数据也是会计领域的常见要求，这使得一刀切的领域模型解决方案变得更糟。它们可能被实现为难以测试和维护的复杂 SQL，或导致域逻辑泄漏到基础设施层。

使用领域事件来整合两个有界上下文可能是个好主意。您可以参考Accounting Pattern，其中 Martin Fowler 建议使用事件来触发会计流程。

【讨论】：

如果考虑到与产品本身（产品历史）紧密相关的产品，我不明白为什么我不应该中断订购。仅使用 sql 意味着将逻辑移到域之外，这不是一个好主意。产品会计与产品本身（它的销售历史）相关联，我不明白为什么应该将其移至另一个上下文，它依赖于这个聚合根。
@GeoC。产品是一个业务概念，可以在不同的有界上下文中映射到不同的域模型（甚至不是基于 ddd）。不同的限界上下文有不同的要求，这使得开发通用领域模型变得非常困难。

【解决方案2】：

您可能应该为此研究CQRS 模式。您以两种方式使用域对象。除非您从数据库中获取所有订单并在某个循环中遍历它们，否则您无法获得所有产品销售。那会很慢。这就是为什么报告通常是在另一个有界上下文中完成的，正如 Hippoom 所建议的那样。读一读。

【讨论】：