假设订单的典型模型：
订单（aggregateRoot）{OrderLine} OrderLine（entityInsideOrderAR）{产品;数量} 产品（aggregateRoot）{name}
这是一个适合会计目的的设计吗？我的意思是，calculateTotalProductSales（）应该在哪里？引用应该是非循环的，所以如果产品有一个OrderCollection，这将不是一个好的设计。即使对于Product的特殊聚合子项，ProductHistory也应该引用Order，并且再次加载一个对象（循环引用）。
这个案例的优秀设计是什么？基本上我需要根据产品销售进行一些计算（countTotalSalesForProduct（），calculateTotalSalesForProduct（）等...一些简单的会计计算）。
P.S。 ：将OrderLine提升一级并使其成为自己的AR是一个很好的想法吗？
答案 0 :(得分：2)
可以将会计功能划分为有限的上下文。可以在不破坏现有订购背景的情况下开发一组独家模型。此外，现实中会计领域不需要很多订单信息（例如发货地址，备注等）。报告和统计数据也是会计领域的常见要求，这使得“一刀切”的域模型解决方案变得更糟。它们可能被实现为复杂的SQL，难以测试和维护，或导致域逻辑泄漏到基础架构层。
使用域事件来集成两个有界上下文可能是一个好主意。您可以参考Accounting Pattern，其中Martin Fowler建议使用事件来触发会计流程。
答案 1 :(得分：1)
你应该考虑CQRS模式。您以两种方式使用域对象。除非从数据库中获取所有订单并在某个循环中遍历它们，否则无法获得所有产品销售。那将是缓慢的。正如Hippoom建议的那样，这就是为什么报告通常在另一个有限的背景下完成的原因。读一读。