僕は、ドメインモデルの設計が読み込まれることの考慮から解放されると思っていて、EmpRepository#resolveByName, … など集約のID以外の属性で読まれることを意識した設計になることがよくあります。リポジトリはもうKey, Valueでいい気がしています。
複雑なクエリはドメイン層のリポジトリでサポートするのではなくアプリケーションに合わせて最適化した方が費用対効果があると思った。W系にはドメインモデルだけでR系は要件に応じてリードモデルとDAOがあればいいかなと。ビジネス価値ってつまるところ振る舞いを起こすところにあるので。
ユビキタス言語で表現されたモデルがドメインモデルなんですが、ActiveRecordにみるようなuser.saveはドメインオブジェクトの責務ではないです(saveするという語彙がユビキタス言語にない場合)。リポジトリか、インフラストラクチャの責務の可能性がありますね。
ドメインモデルのメソッドの、暗黙的パラメータとしてリポジトリを渡すと、関連爆発を抑えつつ、表現力を維持できることがわかった。これはすごい。 #scalajp #dddjp
ファクトリとリポジトリの明確な定義分類、素晴らしい。ファクトリはドメインにおけるモデルの誕生を、リポジトリはライフサイクルの誕生より後（中期以降）を担当するべき、と。#DDD