DDD：集合ルート間の関連付けをモデル化する方法

Question

以下のように集計ルートがあります。

@AggregateRoot 
class Document { 
    DocumentId id; 
} 

クライアントによって与えられた問題文は

ので、モデルは

//Design One 
@AggregateRoot 
class Document { 
    DocumentId id; 

    //Since Document is an aggregate root it is referenced by its id only 
    Set<DocumentId> attachments; 

    attach(Document doc); 
    detach(Document doc); 
} 

につながるリファクタリングしかし、これだけでモデルが勝った「文書に添付ファイルとして複数のドキュメントを持つことができる」ですクライアントが添付ファイルに関するメタ情報（添付した人や添付されたときなど）を保存したいときに十分です。これにより、別のクラスの作成につながります。

class Attachment { 
    DocumentId mainDocument; 
    DocumentId attachedDocument; 
    Date attachedOn; 
    UserId attachedBy; 

    //no operation 
} 

と私は考えることができ、モデリングのさまざまな可能性を以下に示す

//Design Two 
@AggregateRoot 
class Document { 
    DocumentId id; 
    Set<Attachment> attachments; 

    attach(Document doc); 
    detach(Document doc); 
} 

以下のように我々は再び文書モデルをリファクタリングできます。

1. 私は、私は、集約ルートとしてAttachmentクラスをモデル化し、文書が添付されるたびにそれらを作成するためにイベントを使用することができ、設計1で行く場合。しかし、それは集約ルートのようには見えません。
2. デザインを2つ選択すると、Attachmentクラスを値オブジェクトまたはエンティティとしてモデル化できます。
3. CQRSを使用している場合は、デザインモデル1とモデルAttachmentをクエリモデルとして使用し、イベントを使用して入力できます。

このシナリオをモデル化する正しい方法はありますか？私が言及した他のものをモデル化する他の方法はありますか？

Answer 1

エンティティではなく、渡す値によってコードを管理しやすくなる場合があります。アタッチ/デタッチがドキュメント全体を気にしない場合は、気にするビット（インターフェース分離原理とも呼ばれます）を渡してください。クライアントが添付ファイルに関するいくつかのメタ情報を格納するために望んでいるとして、それが接続されたとき、誰がそれを添付など

attach(DocumentId); 
detach(DocumentId); 

だけでこのモデルは、十分ではありません。

はい、多くの意味があります。

これはこのシナリオをモデル化する正しい方法ですか？

提供されていない十分な情報（「それが依存」というのが丁寧なやり方。）

集計境界は通常、むしろ構造や関係よりも、行動を調べることによって発見されています。アタッチメントの関係は、追加/削除できる不変の値か、時間の経過とともに変化する内部状態のエンティティですか？添付ファイルを変更した場合は、その他の情報が必要です。