別の集約との関係を持つ集計を作成するときのDDD整合性チェック

Question

別の集計との関係を持つ新しい集計を作成する場合、関係集計はどこでチェックする必要がありますか？それがアプリケーションサービスにあるのか、または一部のドメインサービスによって工場内にあるのでしょうか？

class ApplicationService 
{ 
    public void CreateNewAr(relationArId, relationArId2) 
    { 
     var relationAR = _relationArRepository.getById(relationArId); 
     if(relationAR == null) 
     throw NotFoundException(); 

     var relationAR2 = _relationAr2Repository.getById(relationArId2); 
     if(relationAR2 == null) 
     throw NotFoundException(); 

     var newAr = _newArFactory.CreateFromAr1And2(relationAR.id, relationAR2.id); 
     _newArRepository.Insert(newAr); 
     _uow.Commit(); 
    } 
} 

または

class NewArFactory 
{ 
    public NewAr CreateFromAr1And2(relationArId, relationArId2) 
    { 
     var relationAR = _relationArRepository.getById(relationArId); 
     if(relationAR == null) 
     throw NotFoundException(); 

     var relationAR2 = _relationAr2Repository.getById(relationArId2); 
     if(relationAR2 == null) 
     throw NotFoundException(); 

     var newAr = new NewAr(relationAR.id, relationAR2.id); 
     return newAr; 
    } 
} 

Answer 1

TL; DR：ドメインのために行きます。工場かどうかは別の議論です。

NewArFactoryがドメインの変更を制御している場合、NewArFactoryは集約されていますか？

集約の目的は変更を制御することです。これは可能な実装の詳細ですが、必ずしも集約自体を永続化する必要はありません。永続性から集約を取得する場合、必ずしも集約テーブルを持つ必要があります（または複数のテーブルに分割する）ことを意味します。リポジトリは、永続性の情報を使用して集約を構築し、それを返すために必要なデータ（つまりエンティティ - VO ID）を取得できます。集約（集約ルートを介して）はエンティティの変更を制御し、新しい状態が維持されます。

ドメイン内の物は、実生活のように、薄い空気からは現れません。起こっていることを理解しよう。自動車が組み立てられ、製品が中国から私たちのウェアハウスに到着し、ユーザーが自分のWebアプリケーションに自分自身を登録しました。次に、ドメイン表現の作成（ドメインユビキタス言語を使用したユースケースとプロセス）のより良いコンテキストを提供します。そこから;変更を管理するための集約が現れます。

永続化されていない1つの集約でも、永続化された集約が作成される可能性があります。Uff、このことはテーブル内の完全な実ドメインコンテキストなしで説明するのが非常に複雑になります。

注：この回答の作成には、集計は損なわれていません。