質問: 「実践ドメイン駆動設計」には、以下のような記述があります。 > > 集約の内部からリポジトリを使うことは、できる限り避けるべきだ > > *(7章 サービス の冒頭 ...電子書籍版なのでページ番号不明)* > > > リポジトリを集約内から使って検索することもできる。このテクニックは**切り離されたドメインモデル**と呼ばれており、遅延読み込みの方式のひとつである。 > > *(10章 集約 - 10.4)* > > > **切り離されたドメインモデル**は、一般的にあまり好ましくない手法だ > > *(10章 集約 - 10.8)* > > > 他にも各所に似たようなことは書かれているのですが、その理由が分かりません。 一応、次のような記述もあります。 > > さらに、高トラフィックでサイズが大きく、高いパフォーマンスが求められるドメインのことを考えてみよう。...(中略)...リポジトリやドメインサービスのインスタンスを集約に注入するオーバーヘッドは、どの程度になるだろう? > > > 確かにアプリケーションサービスへのリポジトリのDIに比べ、インスタンスの数自体が増えやすい集約にリポジトリをDIするのは、パフォーマンス上の問題がありそうです。 しかしこれは、「集約の内部からリポジトリを使うことを避ける理由」の本質なのでしょうか? 私の直観的には、業務ロジックを扱うドメインの中から、業務ではなく永続化の責務を担うべきリポジトリを使うのは、何となく変な気がします。 ただ、そもそもリポジトリは「永続化ロジック」を抽象化したものであると考えると、抽象化してんだから良いじゃん、という気もします。 つまり、まるでコレクションであるかのように扱えば(そういうインタフェースにすれば)、ドメインをあまり汚さないようにも思えるのです。 この**切り離されたドメインモデル**が「一般的にあまり好ましくない」理由の本質は一体何でしょうか? パフォーマンスのような技術的な問題以外に、「ドメインモデルの設計思想としての理由」などがありますか?
回答: Rule: Reference Other Aggregates by Identity と言ってますので、リポジトリの中で他の集約を持つことは、このルールに引っかかるということではないでしょうか。より関連性が高まるので`一般的にあまり好ましくない`と表現しているのではないかと思います。