複雑な製造管理システムの構築。私は何十ものエンティティを持っていますが、子集計として意味があるように見えるものもあれば、明らかにそうでないものもあります。
さまざまなエンティティを、重要度の高い順にリストしてみましょう。
- 作業命令
- 見積もり
- 請求書
- 保証
- 認証
- 不適合
- 運送
- シリアルログ
- セリログ
- 順序
- 手直し
- 消耗品
- RepairLineItem
これらはほんの一部ですが、私の質問に最も関連しています。
それらのすべて (請求書を除く) は、Workorder (TrackingID) に関連してのみ存在します。
ワークオーダーは、不適合や保証などを持たなくても存在できますが、シーケンスは例外です。ワークオーダーには少なくとも 1 つのシーケンスが必要です。
リワークは、それ自体のシーケンス コレクションを集約します。事後に作成されたシーケンスは、リワークに属している必要があります。
Workorder は Quote なしで存在する場合がありますが、Quote には少なくとも Consumable および RepairLineItem へのアクセスが必要です (作業範囲の合計を集計するために使用されます)。
当初、これらのエンティティはすべて Workorder/AR の集約としてモデル化されていましたが、これは設計の悪さを叫んだため、それぞれ独自のリポジトリを使用して独自の集約ルートを作成し始めました。ただし、これを行うことで、制約を強制する機能が失われました。
たとえば、作業指示書が作成されると、承認されたマニュアルによって指示された固定数のシーケンスが含まれます。これらのシーケンスは、インスペクタによってオンまたはオフにチェックできます。次に、その作業指示書のトラベラーが印刷され、作業指示書が変更されないようにロックされます。間違いを修正するため、または元のマニュアルに重要なステップが欠けていたために、新しいシーケンスを追加する必要がある場合があります。これは、再作業が作成され、新しいシーケンスが作業指示書に追加された場合です。
これらのシーケンスが追加されると、変更を分析し、場合によっては完了予定時刻を再スケジュールするために、workorder 集約ルートに通知する必要があります。
同様に、作業指示書には、修理品目または消耗品のセット リストがあります (消耗品は、検査後にいつでも追加できます)。これらのエンティティのいずれかの数量が変更された場合、見積もりの集計に通知する必要がある作業指示書に浸透する必要があるため、合計コストを更新し、適切な関係者に電子メールで通知することができます。
明らかに、モノリシックな AR を持つことは意味がありません (特にパフォーマンスの観点 - これは AJAX Web ベースのアプリとして実装されます)。作業指示書のリポジトリは、次のようなメソッドで複雑になります。
selectAllConsumablesForWorkOrder()
selectAllRepairItemsForWorkOrder()
selectAllCertificationsForWorkOrder()
...
私の質問は、上記のシナリオと要件を考慮して、これらの不変ルールを適用しながら、より小さな集約ルートを使用するにはどうすればよいですか? すべてが WorkOrder/AR によってカプセル化されていれば、上記の要件を簡単に適用できることがわかります。
私のDDDの理解は完璧にはほど遠いので、優しくしてください:)
AR のすべてについて間違った印象を持っている可能性がありますが、私が読んだほとんどの記事は、製品と複数の品目の例を使用して、これを示唆しているようです。これが事実上この作業指示書ですが、各項目は他の集計と共有される可能性があります...
どんな経験や意見も歓迎します
よろしく、アレックス