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

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

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

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

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

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

この **切り離されたドメインモデル** が「一般的にあまり好ましくない」理由の本質は一体何でしょうか？  
パフォーマンスのような技術的な問題以外に、「ドメインモデルの設計思想としての理由」などがありますか？
CC BY-SA 3.0
2015-08-13T11:33:02.133
14388
2016-11-16T16:03:38.973
2020-06-17T08:14:45.997
-1
8078
question
ドメイン駆動設計
DDDで集約の内部からリポジトリを使うことを避ける理由
[Rule: Reference Other Aggregates by
Identity](http://www.informit.com/articles/article.aspx?p=2020371&seqNum=4)
と言ってますので、リポジトリの中で他の集約を持つことは、このルールに引っかかるということではないでしょうか。より関連性が高まるので`一般的にあまり好ましくない`と表現しているのではないかと思います。
CC BY-SA 3.0
2015-08-20T06:19:17.117
14654
2015-08-20T06:19:17.117
5008
14388
answer
・ドメインオブジェクトは、業務上の判断／加工／計算のロジックだけを持つ  
・業務上の記録／参照の関心事（永続化の関心事）は、アプリケーション層が担当する

そういう役割分担にしたほうが、業務ロジックの整理がやりやすいと思います。

永続化は、処理のタイミングや処理の順番に依存しやすくなります。ドメイン層には、そういう手続き的な依存性を持ち込まないほうが、ドメインオブジェクトに記述する業務ロジックをわかりやすく保つことができると思います。
CC BY-SA 3.0
2016-11-16T16:03:38.973
30460
2016-11-16T16:03:38.973
8260
14388
answer