事件溯源聚合中关联实体的处理方案咨询

针对你遇到的商品（Product）聚合根依赖分类（Category）溢价计算价格的问题，常见的处理方案有以下几种：

1. 把分类溢价嵌入商品事件流 #

当商品绑定分类，或者分类的溢价发生变更且需要同步到关联商品时，将当前的溢价比例直接写入商品的事件中。比如ProductAssignedToCategory事件里，除了CategoryId，再加一个PremiumRate字段。这样在重建Product聚合时，就能从事件中拿到溢价数据，CalculateFinalPrice方法可以直接使用。

• 好处：聚合根完全独立，重建时不需要依赖任何外部数据，符合事件溯源的设计原则。
• 注意：如果业务规则要求用实时的分类溢价（而非绑定当时的溢价），这个方案就不适用；如果是用绑定当时的溢价，后续分类溢价变更不需要影响已绑定的商品，那这个方案最省心。

2. 让聚合根依赖领域服务获取外部数据 #

给Product的CalculateFinalPrice方法传入一个领域服务（比如CategoryPremiumProvider），方法内部通过这个服务，用CategoryId去获取实时的分类溢价比例，再完成计算。

• 实现方式：在调用聚合根方法时，把这个服务作为参数传进去，比如product.CalculateFinalPrice(categoryPremiumProvider)。
• 好处：能获取最新的分类状态，不用在事件流里冗余存储溢价数据。
• 注意：这是DDD允许的做法——聚合根可以依赖领域服务来获取外部上下文的必要数据，只要聚合根自身的核心状态还是由事件流重建的就行，不算破坏聚合的自治性。

3. 用只读投影处理查询场景 #

如果计算最终价格是为了查询展示（比如用户看商品详情），而非命令操作（比如下单结算），那就用CQRS的思路，单独构建一个只读投影：

• 同时监听商品事件和分类事件，在投影层维护一个视图模型（比如ProductPriceView），里面包含商品的基础价格、对应的分类溢价。
• 要查最终价格时，直接从这个投影里读数据计算，或者投影里直接存计算好的最终价格，完全不用碰Product聚合根。
• 好处：彻底分离命令和查询的职责，避免聚合根在查询场景下依赖外部数据，性能也更好。

4. 重新评估聚合边界（谨慎使用） #

如果分类的溢价规则和商品价格绑定极深，且分类几乎不会独立变更，可以考虑调整聚合边界：把Category作为Product聚合的内部实体，或者合并成一个聚合根。但你提到一个分类对应多个商品，这个方案大概率不适合，不过可以作为边界设计的参考方向。

内容的提问来源于stack exchange，提问作者rbasniak