DDDで集約の内部からリポジトリを使うことを避ける理由


「実践ドメイン駆動設計」には、以下のような記述があります。

> 集約の内部からリポジトリを使うことは、できる限り避けるべきだ  
>  _(7章 サービス の冒頭 ...電子書籍版なのでページ番号不明)_
>
> リポジトリを集約内から使って検索することもできる。このテクニックは **切り離されたドメインモデル**
> と呼ばれており、遅延読み込みの方式のひとつである。  
>  _(10章 集約 - 10.4)_
>
> **切り離されたドメインモデル** は、一般的にあまり好ましくない手法だ  
>  _(10章 集約 - 10.8)_

他にも各所に似たようなことは書かれているのですが、その理由が分かりません。  
一応、次のような記述もあります。

>
> さらに、高トラフィックでサイズが大きく、高いパフォーマンスが求められるドメインのことを考えてみよう。…（中略）…リポジトリやドメインサービスのインスタンスを集約に注入するオーバーヘッドは、どの程度になるだろう？

確かにアプリケーションサービスへのリポジトリのDIに比べ、インスタンスの数自体が増えやすい集約にリポジトリをDIするのは、パフォーマンス上の問題がありそうです。  
しかしこれは、「集約の内部からリポジトリを使うことを避ける理由」の本質なのでしょうか？

私の直観的には、業務ロジックを扱うドメインの中から、業務ではなく永続化の責務を担うべきリポジトリを使うのは、何となく変な気がします。  
ただ、そもそもリポジトリは「永続化ロジック」を抽象化したものであると考えると、抽象化してんだから良いじゃん、という気もします。  
つまり、まるでコレクションであるかのように扱えば（そういうインタフェースにすれば）、ドメインをあまり汚さないようにも思えるのです。

この **切り離されたドメインモデル** が「一般的にあまり好ましくない」理由の本質は一体何でしょうか？  
パフォーマンスのような技術的な問題以外に、「ドメインモデルの設計思想としての理由」などがありますか？




[Rule: Reference Other Aggregates by
Identity](http://www.informit.com/articles/article.aspx?p=2020371&seqNum=4)
と言ってますので、リポジトリの中で他の集約を持つことは、このルールに引っかかるということではないでしょうか。より関連性が高まるので`一般的にあまり好ましくない`と表現しているのではないかと思います。




[Rule: Reference Other Aggregates by
Identity](http://www.informit.com/articles/article.aspx?p=2020371&seqNum=4)
と言ってますので、リポジトリの中で他の集約を持つことは、このルールに引っかかるということではないでしょうか。より関連性が高まるので`一般的にあまり好ましくない`と表現しているのではないかと思います。

