DDD聚合内实体为何用one to some而非one to many及超量拆分原因

• 事务与加载性能控制
  聚合是DDD中数据修改的最小事务单元，每次操作聚合根时，默认需要把整个聚合关联的所有实体都加载到内存中。如果SnackMachine关联的PurchaseLog数量过多，单次聚合加载会产生不必要的数据库IO开销，内存占用也会随之升高。30是领域驱动设计实践中总结的常规业务场景下的性能友好阈值，超过该值后，普通操作的性能损耗会出现可感知的上升。
• 降低并发冲突概率
  同一时间只能有一个事务修改同一个聚合，否则会触发并发冲突。如果把PurchaseLog放在SnackMachine聚合内，每产生一笔购买记录都要锁定整个SnackMachine聚合，高购买频率下会导致大量操作排队、冲突报错。拆分后PurchaseLog为独立聚合，新增日志仅需锁定自身的聚合根，完全不会影响SnackMachine的库存修改、出货等其他核心操作。
• 符合聚合单一职责原则
  SnackMachine聚合的核心职责是管理设备状态、库存、金额计算、出货逻辑，购买日志属于审计类附属数据，本身不属于SnackMachine的核心业务边界。当日志量积累到一定程度后，继续放在同一聚合内会导致聚合职责膨胀，后续维护难度会大幅提升。
• 减少不必要的一致性校验开销
  聚合内所有实体的变更都需要满足聚合根定义的全局一致性规则，而PurchaseLog本身是不可变的事后审计数据，仅需要保证自身的字段准确性，不需要和SnackMachine的实时状态做强一致性绑定。拆分后两类聚合仅通过SnackMachine的ID做关联即可，不需要额外维护冗余的一致性校验逻辑。

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