在第134页（DDD：解决软件核心中的复杂性）作者通过使POPurchase Order 成为包含许多PO共享）：PO Line ItemsPartPart
与此模型一致的实现将保证与 PO 及其项目相关的不变性，而零件价格的更改不必立即影响引用它的项目。
...
但这不是必须始终强制执行的不变量。通过降低订单项对零件的依赖，我们可以避免争用，更好地反映业务现实。同时，加强采购订单与其行项目的关系，保证了一条重要的业务规则将得到遵守。
作者认为，零件价格的变化不必立即传播到引用它的PO聚合，因为：
在更新特定PO时锁定部分可能会导致争用（由于多个PO同时尝试锁定同一部分的可能性 ）
部件的修改频率低于PO ，因此PO具有无效数据的可能性相对较小
a) 我理解作者的论点，但PO的一致性不应该是这种模型中的重中之重，因此这些部分应该与更新的PO锁定在一起，即使存在争用的风险？
b）相比之下，在第 176、177 页作者确实发现有必要在单个事务中强制跨越两个聚合的不变量（即，当Handling Event添加时，Delivery History也应在同一事务中相应地更新）：
Delivery History 包含与其 Cargo 相关的处理事件集合，并且必须将新对象作为事务的一部分添加到该集合中。如果未创建此反向指针，则对象将不一致。
...
添加处理事件时需要更新交付历史记录会导致交易中涉及的 Cargo AGGREGATE。
我不明白为什么在这个例子中保持单个事务中的一致性比在PO例子中更重要？
注意（我假设通过“反向指针”他指的是Handling Event实例？）
c) 作者没有作为替代方案提出实现 Optimistic Concurency check是否有特殊原因，其中Parts 表将包含一个rowversion字段，我们的代码将在每次更新某些PO时检查该字段？
d）顺便说一句，为什么必须Price将值复制到Line Item（图 6.11，第 134 页）？PO的不变量不能通过检查Part实体来检查价格吗？
谢谢