ドメインモデルにおける集約ルートには、グローバル空間で一意なIDが必要？


ドメインモデル（ドメイン駆動設計）では、集約ルートにはグローバル空間で一意なIDを付けるべし、という情報を得ました。  
DDD本にも、「（集約）ルートエンティティはグローバルな同一性を持つ」という記述があります。  
※ごめんなさい、電子書籍なのでページ番号分かりません。集約の不変条件についての記述です。  
このことについて疑問がありますので教えて下さい。

例えば、プロジェクト管理アプリケーションを作っているとします。  
ざっくりとした要件はこんな感じです。

  1. プロジェクトを複数管理できる
  2. ひとつのプロジェクトは複数のタスクから構成される
  3. 人員を複数管理できる
  4. 人員は、色々なプロジェクトのタスクに割り振られる

こうすると、集約としては「プロジェクト」と「人員」が出てくるかなと思います。  
どちらも「プロジェクトID」と「人員ID」という、グローバル空間で一意なIDを付ければ良さそうです。  
また、「タスク」は「プロジェクト」の集約に含まれそうなので、そういったIDは付けません。

ここからが本題なのですが、もしこのアプリケーションをクラウドサービス化したとしたらどうなるでしょうか。  
「プロジェクト集約」とか「人員集約」とかは、サービスの契約者ごとに管理されなければなりません。  
つまり、「サービス契約者ID」と「プロジェクトID」が揃わなければ、「プロジェクト」が特定できません。

これでは「プロジェクト集約」はグローバルなIDを持たないことになりますが、これは許されるのでしょうか？  
あるいは、「プロジェクト集約ルート」は集約ルートからただのエンティティに降格するのでしょうか。

そもそも集約ルートがグローバルなIDで管理されなければならない、というのがいまいちピンときていないのですが・・・  
上位の集約のID（上記例ではサービス契約者ID）にぶら下がるのでは、ダメなのでしょうか？  
それとも、DDD本にある「グローバルな同一性」とは、単一のIDを要求するものではなく、「サービス契約者ID＋プロジェクトID」という複合的なIDであっても、OKということでしょうか？




エバンスのドメイン駆動設計で書いてある「グローバルな同一性」というのは、「グローバルなID」とは等価ではないと思いますよ。

ある実体（エンティティ）が同じものであることを識別する時に、オブジェクトのIDやデータベースの主キーの議論と、「人がどう判断するか」の議論はいったんは分けて考えたほうが良いです。

ドメイン駆動設計の文脈で言えば、「同一性」の議論で大切なのは、利用者が、どんな情報を判断材料として、同じプロジェクトと別のプロジェクトを認識するか、です。

あるサービス契約者（とのそのサービスの利用者）が、自分が見えるすべてのプロジェクトの範囲で、プロジェクト名で判断できるなら、同一性のキーとなる情報はプロジェクト名です。

サービスの運営者（とシステムの開発者）から見れば、理屈の上では、プロジェクトの識別は、サービス契約者＋プロジェクト名ということになりますが、実際に、そういう識別が必要になるケースは、業務的にはないんじゃないでしょうか？
全てのサービス契約者の全てのプロジェクト一覧、というような画面が必要かどうか、ということです。

おそらく、サービス契約者一覧は必要だが、プロジェクト一覧は、特定のサービス契約者ごとのプロジェクト一覧があれば十分かと思います。この場合、プロジェクトを表すオブジェクト自身が、サービス契約者まで含めて識別情報を持つ必要は、ないと思います。

もし、全てのサービス契約者にまたがってプロジェクトを一覧したい、というニーズがあるのなら、プロジェクトの同一性は、サービス契約者＋プロジェクトの組み合わせの設計になるかと思います。




エバンスのドメイン駆動設計で書いてある「グローバルな同一性」というのは、「グローバルなID」とは等価ではないと思いますよ。

ある実体（エンティティ）が同じものであることを識別する時に、オブジェクトのIDやデータベースの主キーの議論と、「人がどう判断するか」の議論はいったんは分けて考えたほうが良いです。

ドメイン駆動設計の文脈で言えば、「同一性」の議論で大切なのは、利用者が、どんな情報を判断材料として、同じプロジェクトと別のプロジェクトを認識するか、です。

あるサービス契約者（とのそのサービスの利用者）が、自分が見えるすべてのプロジェクトの範囲で、プロジェクト名で判断できるなら、同一性のキーとなる情報はプロジェクト名です。

サービスの運営者（とシステムの開発者）から見れば、理屈の上では、プロジェクトの識別は、サービス契約者＋プロジェクト名ということになりますが、実際に、そういう識別が必要になるケースは、業務的にはないんじゃないでしょうか？
全てのサービス契約者の全てのプロジェクト一覧、というような画面が必要かどうか、ということです。

おそらく、サービス契約者一覧は必要だが、プロジェクト一覧は、特定のサービス契約者ごとのプロジェクト一覧があれば十分かと思います。この場合、プロジェクトを表すオブジェクト自身が、サービス契約者まで含めて識別情報を持つ必要は、ないと思います。

もし、全てのサービス契約者にまたがってプロジェクトを一覧したい、というニーズがあるのなら、プロジェクトの同一性は、サービス契約者＋プロジェクトの組み合わせの設計になるかと思います。

