「製造工場」のソフトウェア システムをモデル化しようとしています...
システム全体の中核にあるのは「作業指示書」です。ほぼすべてのエンティティ (ここには示されていないか、問題の AR の一部ではありません) は何らかの形で作業指示書に接続されています。ただし、主に次のようになります。
+ WorkOrder_Root
+ TrackingID: Property (UID)
+ DateReceived: Property
+ DateApproved: Property
+ PartName: Property
+ PartNumber: Property
+ Rework: Collection (1:m)
+ SerialLog: Collection (1:m)
+ CeriLog: Collection (1:m)
+ Sequences: Collection (1:m)
+ Dimensions: Collection (1:m)
+ Consumables: Collection (1:m)
+ Quoting: Single
+ Invoice: Single
+ Warranty: Single
+ Certification: Single
これは大規模な AR です (不完全です -- プロパティ/コレクションは他にもあります。ここ数日でさらにいくつかの記事やミニブックを読んだので、もっと AR に分解してみる必要があるかどうか真剣に考えています。
http://www.sapiensworks.com/blog/post/2012/04/18/DDD-Aggregates-And-Aggregates-Root-Explained.aspx
上記のコレクションはすべてエンティティのコレクションですが、作業指示書のコンテキスト外では意味をなさないものはありません。
作業指示書がないと請求できません。作業指示書がないと見積もりもできません。すべては作業指示書に依存しています。
私の主な関心事は、潜在的な並行性の問題であると私が理解していることです。たとえば、誰かが W/O: 66354 の見積もりを変更し、他の誰かが手直しを追加している場合、何らかの競合状態が存在します。
リワークは価格を変更する可能性があるため、リワークが完了する前に見積もると、おそらくリワークはそれ自体のARであるべきだと思いますが、すべてのリワークはワークオーダーに属し、最初にワークオーダーを開く/ロードしないとリワークを構築できません.
モデル内の他のすべての AR は比較的単純で、多くても 3 つの子エンティティと少数のプロパティしかありませんが、作業指示は獣であり、この「神」オブジェクトを使用することでどのような種類の問題が予想されるのだろうか???
EDIT：私は以下を読みました（http://practical-ddd.blogspot.ca/2012/07/designing-aggregates.html）不変条件は私に二度考えさせました。シーケンスが関連付けられている作業指示書を通知する必要なく、シーケンスを更新または変更できる場合、シーケンスは AR の候補になりますか??? シーケンスへの変更は WorkOrder_Root に反映される必要があるため、シーケンスは悪い例かもしれません...しかし、それでも...私はここで正しい道を進んでいますか? ビジネス ルールに任せる (論理的またはデータ中心の組織ではなく)...
よろしく、アレックス