最初、私の DDD リポジトリは次の例のようになりました。
class PersonRepository {
Person findByID(id)
List<Entity> findAll()
List<Entity> findWithRegex(String)
}
内部的には、エンティティ オブジェクトを DTO オブジェクトに変換する GUI を提供するサービス
今、私はCQRSに入ろうとしています。他の例を見た後、私のレポは次のようになるはずです:
class PersonReadModel {
Person findByID(id)
List<DTO> findAll()
List<Entity> findWithRegex(String)
}
DDD のみを使用すると、リポジトリは Entity および List オブジェクトのみを返しました。CQRS では、多くの読み取りが UI のみに使用されるため、直接 DTO を返す多くの読み取り操作があるため、PersonReadModel は従来の DDD リポジトリとはまったく異なります。
この仮定は正しいですか?List のみを返し、Entity および List オブジェクトを返すPersonRepositoryを保持するには、PersonReadModelを使用する必要がありますか? PersonReadModelは、ルート集約の内部リポジトリへのリンクを含むサービスにする必要がありますか?
DTO とエンティティの両方に ID フィールドがあるため、DTO をそのエンティティに関連付けることができます。ただし、表示される DTO が、ドメイン モデルに存在するエンティティとは異なるリビジョンであることを懸念しています。私が見たすべてのCQRSの例には、 identityフィールドを持つ DTO と Entities がありますが、 Revision はありません。
リビジョンは私が気にする必要があるものですか?
私の推測では、アプリケーション層の GUI コードは DTO とリビジョンを含むメッセージを作成し、ドメイン層は要求されたコマンドが最新バージョンで作成されたことを確認するために使用します。