134 ページ ( DDD: Tackling Complexity in the Heart of Software ) で、著者はPOを を含む集約ルートにすることで発注書モデルを改善し、エンティティはそれ自体の集約のルートになります(集約ルートを作成することは理にかなっています。多くのPOによって共有されます):Purchase Order PO Line ItemsPartPart
このモデルと一致する実装は、PO とそのアイテムに関連する不変を保証しますが、部品の価格の変更は、それを参照するアイテムにすぐに影響を与える必要はありません。
...
しかし、これは常に強制しなければならない不変条件ではありません。ラインアイテムの部品への依存をよりゆるくすることで、競合を回避し、ビジネスの現実をよりよく反映します。同時に、PO とその品目の関係を強化することで、重要なビジネス ルールに従うことが保証されます。
著者は、部品価格の変更は、それを参照するPO集計にすぐに伝播する必要はないと主張します。
特定のPOが更新されているときにパーツをロックすると、競合が発生する可能性があります (複数のPOが同時に同じパーツのロックを取得しようとする可能性があるため ) 。
パーツはPOよりも頻繁に変更されないため、 POが無効なデータを持つ可能性は比較的小さい
a) 私は著者の主張を理解していますが、そのようなモデルでは PO の一貫性が最優先事項であるべきではないのでしょうか?
b) 対照的に、ページ 176、177 で、著者は 1 つのトランザクション内で 2 つの集計にまたがる不変条件を強制する必要があることを発見しました (つまり、Handling Eventが追加された場合Delivery History、同じトランザクション内で適宜更新する必要もあります)。
配送履歴は、その貨物に関連する処理イベントのコレクションを保持し、トランザクションの一部として新しいオブジェクトをこのコレクションに追加する必要があります。このバック ポインターが作成されていない場合、オブジェクトに一貫性がなくなります。
...
処理イベントを追加するときに配送履歴を更新する必要があるため、貨物の AGGREGATE がトランザクションに関与します。
この例では、単一のトランザクション内で一貫性を維持することが、 POの例よりも重要である理由がわかりません。
注（「バックポインタ」Handling Eventによって彼はインスタンスを参照していると思いますか？）
c) 作成者が別の方法としてOptimistic Concurency checkの実装を提案しなかった特定の理由はありますか? この 場合、Parts テーブルには、 POが更新されるたびにコードが検査するrowversionフィールドが含まれます。
d) ところで、なぜPrice値をコピーする必要があるのですかLine Item(図 6.11、134 ページ)。POPartの不変式は、エンティティを検査して価格を確認できませんか?
ありがとうございました