DDD集計ルートの選択

Question

時間トラッキングアプリケーションの構築集約ルートを設計する最適な方法を決定しようとしています。

基本的なコアエンティティは、クライアント、プロジェクト、従業員、ProjectAssignment、Department、タイムシートです。クライアントには1つ以上のプロジェクトがあり、プロジェクトには1人以上の従業員が割り当てられています（ProjectAssignment経由）。従業員は部門に属し、タイムシートはProject、Employeeともリンクしています。

クライアントは明らかな集約ルートのようです。

私は一種の行くための最善の方法がどうなるかわからないんだけど、他の集合体について

Client -> Project -> ProjectAssignment -> Employee 

...

私が考えていた...

Department -> Employee -> Person 

または従業員を持っており、部門は完全に別々の集約として。従業員は1つの部門と1つの部門にのみ存在することができます。しかし、部門は部門階層を作成するために自己参照しています。

集約ルート間でエンティティを共有する方法をどのように扱いますか？

Answer 1

集計を設計する際には、境界条件と不変条件を考慮する必要があります。 あなたが理解していることから、あなたはただ一つの束縛されたコンテキストだけを議論に持ち込んだ。 従業員は1つの部門にしか存在しないと指定した不変条件については、 私が集計根（ARs）と言うことができるのは、Client、Project、EmployeeおよびDepartmentです。

ProjectAssignmentは、雇用IDと割り当て日のような他のデータのリストを保持するProject ARの値オブジェクトである必要があります。

Timesheetの中の値オブジェクトEmployeeは、のリストと、開始日と終了日のような他のデータを保持することができます。

Employee ARは、その従業員が1つの部門にのみ所属していることをあなたのインバリアントに強制する参照を保持することができます。

Answer 2

DDDは、データ構造やそれらの構造間の関係ではなく、それらのデータおよびこれらの変更に関連する境界で発生する変更に関するものです。 DDDは、単純なアプリケーションを構築し、単一のユーザーに焦点を当て、可能な限り多くのDDD原則を課すことを難しくしている、複数の講座や会議を含む多くの場所で非常によく説明されていません。

ドメイン駆動設計のコア原理は境界です。集約を見つけようとするときは、まず、アプリケーションで実行するプロセスと、そのプロセスを一貫性を持たせるために必要なものについて考えます。この変更を実行する単一のエンティティを作成し、集約内の他の必要なエンティティ（値オブジェクト）でラップします。次に、1つのエンティティを、それらのエンティティで実行されるすべてのプロセスのゲートキーパーとして昇格させます。

データ構造から設計を開始することは、人々がDDDで失敗する理由の1つです。 あなたが提供してくれたことから、あなたの総計はむしろProjectAssignmentで、おそらくTimesheetであるようです。なぜなら、ここにはおそらくコアビジネスロジックがあるからです。他のすべてのものは、簡単なcrudスタイルのアプローチで作成できる値オブジェクト（またはormを使用する必要がある場合はエンティティ）です。エンティティとバリューオブジェクトの違いについては、多くのディスカッションやブログ記事があります。人々はドメイン内の「オブジェクト」に何らかの意味を与える傾向がありますが、ドメインの専門家にとっては、作成に多くの時間を費やしている貴重なオブジェクトは単なる価値です。 ClientまたはDepartmentを集合ルートとして宣伝しないでください。それらは単なる値です。

ひどくお使いにならないでください。あなたのドメインを設計するときに遭遇する多くの事柄は、ドメインエクスポートの価値オブジェクトにすぎません。彼らは真のビジネスエンティティで操作を実行するためにそれらを使用します。彼らはClientの作成方法、Departmentの作成方法、または階層の作成方法を気にしません。彼らは単にそれらを作成し、それらを編集または削除します。したがって、ClientまたはDepartmentを記述するために使用される単語は、単に作成、更新、または削除されます。これらの単語は、ユビキタス言語（ドメイン言語）の非常に貧弱な候補です。ユビキタス言語は、DDDでは過小評価されています。それを適切に使用すると、ビジネスのために重要でないものを設計するのに費やす時間のトーンを節約できます。何かを作成したり何かを更新する必要があると思うたびに、crudを使用してください！作成や更新などの言葉には単純に適用されないため、DDDの原則であなたの自己を悩まさないでください。

DDDは、コラボレーションドメイン内でのみ、ドメインエキスパートにアクセスできる場合にのみ有効です。同時にビジネスエキスパートと開発者の帽子を持つことは本当に難しいです。少なくともグループで、あるいは少なくともペアで設計をして、いくつかのイベントストーミングを試みてください。まともなdddデザインを作成するだけで、私の経験からほとんどの場合失敗します。

Answer 3

集約ルートを選択するときは、トランザクション一貫性と最終的な一貫性のいずれかを選択します。あなたのビジネスルールによって、あなたは最終的な一貫性を好むでしょう。

社員と部署を見てみましょう。あなたのユースケースをチェックしてください：部門/従業員の変更に最終的な一貫性を使用してもかまいません（ユーザは古い構造を時々見られることに同意するでしょうか？）

もしあれば、DepartmentとEmployeeを別々の集約として扱います。従業員の参照部門をIDで作成します。

（たとえば、ユーザーがタイムシートレポートで従業員の間違った出題を許容しないなどの場合）部門をEmployeeエンティティのコレクションを保持する集計にします。 https://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577