質問: はじめまして。 DDDやクリーンアーキテクチャについてある程度勉強をして、それぞれのオブジェクトがどういう役割を担うのかは何となく理解したというレベルにいます。 ただ、実際のサービスをDDD+クリーンアーキテクチャで設計をしようとしてもドメインモデルが何になるのかをいまいちつかめません。 Instagramっぽいサイトを例にして考えています。 ”ユーザーのプロフィールを見る”というユースケースを実装します。 プロフィールで見れる情報として今回は、アイコン、投稿数、フォロワー数、フォロー数、名前、説明文、リンク、投稿した写真一覧を利用します。 閲覧できるプロフィールは自分のプロフィールと相手のプロフィールの2パターンがあって、自分のプロフィールの場合は登録年月日を、相手のプロフィールの場合はそのユーザーをフォローしてるかどうかを表示します。 まず、この場合はユーザーの関心はプロフィールにあるのでプロフィールが一つのドメインモデルになると考えました。 プロフィールはユーザーの登録情報だけで成り立っているものではなく、投稿した写真にも関係があります。 なのでプロフィールはユーザーエンティティをルートとした集約だと考えます。 ただ、これ以上どうやってモデルに落としこむのか考えてもさっぱりわかりません。 ユーザーや写真はエンティティになりそうだな、とかぐらいは考えつくのですが・・・ プロフィールというドメインモデルはどんな属性を持ちどんな振る舞いをするのか、ユースケースは何をするのかなど全然分かりません。 おそらく実際の設計パターンを何回も見ていくうちに感覚を掴めるようになるかと思うのですが・・・ この場合はどんな設計にするべきなのか教えて下さい。
回答: @mok2pok さんが、とてもいい回答を記述してくださっていますが、 一見しただけだと理解できなかったので、自分が調べた補足情報を。 CQRS とは Command and Query Responsibility Segregation パターンであり、アーキテクチャ的なデザインパターンのひとつ。 参照: コマンド(更新系の処理)とクエリ(参照系の処理)のモデルを分離するすることによって、モデルが読み込み・書き込みの両方を考慮しなければならない場合に発生する複雑さを回避しよう、という試みです。 DDD と併用される場合には、 @mok2pok さんのおっしゃるとおり、読み込みのロジックをなくすような、薄い Dto を用意する様子です。