集合体が1つあるとしTicketます。ATicketには1つが割り当てられDepartment、1つ以上が割り当てられEmployeeます。
をインスタンス化する場合Ticket、aが有効/存在および？で作成されてTicketFactoryいることを確認する責任がありますか？TicketDepartmentEmployee
同様に、Departmentまたはを廃止する場合、不変条件を維持するために、新しいまたはがに割り当てられているEmployeeことを確認する責任は何ですか？ドメインに廃止整合性を担当するサービスがあるのでしょうか、それとも結果整合性または何らかの形式のイベントリスニングを採用する必要がある場合ですか？DepartmentEmployeeTicket
を作成するには、aと。の両方への参照が必要TicketFactoryであると宣言されます。それらが実際に存在することを確認することはありません。適切な参照を取得するのは、呼び出し元のコードの責任です。TicketDepartmentEmployee
結果整合性を使用する場合、Departmentおよびの廃止により、廃止をEmployee示すイベントが公開されます。Ticketそのイベントをサブスクライブし、新しい部門と従業員を割り当てるか、タスクに何らかの警告を送信するに関連付けられたハンドラーがあります。
詳細については、効果的な骨材設計をご覧ください。
私は最近DDDの調査を開始したので、あなたが言及した問題のいくつかに遭遇しました。
TicketFactory常に検証済み/適切に構築されたTicketインスタンスを返す必要があると思います。モデルが複雑な場合は、特定のDepartmentまたはEmployeeそれに接続できることを検証するドメインサービスを作成して、ファクトリがそれを使用することができます。それ以外の場合は、すべてを工場に置くことができます。しかし、工場から出てくるものは適切なチケットでなければなりません。
たとえば、他の2つしかTicket知らない場合、 DepartmentandEmployeeリポジトリを使用するドメインサービスがその仕事を成し遂げると思います。関係が双方向の場合は、イベントソーシングを利用できます。また、それが実際にドメインモデルでキャプチャする必要のあるイベントであり、チケットの再シャッフル以外の結果をもたらす場合は、ハンドラーの1つをこのイベントにアタッチしてInvalidTicketHandler。しかし、それが小規模なものである場合は、単純に保ち、不変条件を維持するドメインサービスを用意するだけです。
補足：Departmentおよび/またはEmployeeがそれ自体の集合体である場合は、Ticketそれらの識別子（たとえば、従業員の会社IDまたは部門のIDコード）を介してそれらを参照できます。このようにして、異なるアグリゲート間の整合性の境界を越えないため、整合性をより簡単に実現できます。
FACTORYは、作成するオブジェクトまたはAGGREGATEのすべての不変条件が満たされていることを確認する責任があります。ただし、そのオブジェクトの外部のオブジェクトに適用されるルールを削除する前に、常によく考えておく必要があります。FACTORYは不変チェックを製品に委任することができ、これが多くの場合最良です。[ドメイン駆動設計：ソフトウェアの中心にある複雑さへの取り組み]
Aは質問の種類によって異なりますが、見た目からはアプリケーションレイヤー機能の優れた候補のようです。イベントソリューションには行きませんが、同じオブジェクト内ではなく、レイヤー間でのみ適切であることがわかります。層。