- アプリケーションがリポジトリ(インフラストラクチャ サービス)を使用している場合、リポジトリ インターフェイスはドメイン レイヤー内で定義されますが、その実装はインフラストラクチャ レイヤー内で定義されます。これは、ドメイン モデルに外向きの依存関係がないためです。
a) 特定の (非リポジトリ)インフラストラクチャ サービス InfServがドメイン層内のコードによって呼び出されないことが 100% 確実である場合、 InfServ のインターフェイスをドメイン層内で定義する必要はないと思いますか?
- InfServがドメイン レイヤー内のコードによって呼び出されないと仮定します (そのため、ドメイン レイヤー内でそのインターフェイスを定義する必要はありません)。
a) InfServがアプリケーション層の Servicesによって呼び出される場合、アプリケーション層はインフラストラクチャ層に暗黙的に依存するべきであり、その逆ではないと思いますか? つまり、InfServ のインターフェイスとその実装の両方をインフラストラクチャ レイヤー内で定義する必要があります。
b)アプリケーション レイヤーがインフラストラクチャ レイヤーに依存する方が良い理由は、インフラストラクチャ レイヤーは多くのアプリケーションで再利用できるためです。一方、アプリケーション レイヤーはほとんどの場合、単一のアプリケーションにのみ固有であり、通常は他のアプリケーションで再利用できませんか?
c)ドメイン レイヤー内のコードがリポジトリを使用しないことが 100% 確実である場合、ドメイン レイヤー内でそのインターフェイスを定義する必要はありませんか?
アップデート：
1)
はい。ただし、ドメイン層の定義には、ドメインのファサードとして機能するアプリケーション サービスを含めることができます。アプリケーション サービスは通常、リポジトリやその他のインフラストラクチャ サービスを参照します。ドメインオブジェクトと前述のサービスを調整して、ユースケースを実装します。
a)
... ドメインのファサードとして機能する
「通常の」（私の質問で言及していたもの）アプリケーションサービスもドメインのファサードとして機能すると主張できませんか？
b)
アプリケーション サービスは通常、リポジトリやその他のインフラストラクチャ サービスを参照します。
あなたの返信から、「通常の」アプリケーションサービスは通常インフラストラクチャサービスを参照しないことを示唆しているように見えますが（おそらくそうではありません）、実際には（私の知る限り）参照していますか?!
2)
a)
私は通常、前述のようにアプリケーション サービスをドメイン層にマージします。
「通常の」アプリケーション レイヤーも BLL レイヤーの一部であるため、ドメイン レイヤーとマージされているとは言えません(実際にはドメイン レイヤーの上にあります) 。
b)
私は六角形の建築様式に固執する傾向があります...
Hexagonal アーキテクチャには、アプリケーション層(つまり、アプリケーション サービス)の明示的な概念がないように見えますか?
c)
ドメイン層でリポジトリ インターフェイスを宣言する利点の 1 つは、ドメインのデータ アクセス要件を指定できることです。
では、ドメイン コードで使用しない場合でも、ドメイン レイヤーにリポジトリ インターフェイスを含める必要がありますか?
2 番目の更新:
2a)
「通常の」アプリケーション サービスと呼ばれるものがドメインとやり取りする場合、それをドメインの「レイヤー」の一部にすることは許容できると思います。ただし、ドメインは周囲のアプリケーション サービスに直接依存すべきではないため、必要に応じてそれらを個別のモジュールに分割することができます。
アプリケーション層（従来の階層化アーキテクチャ）の設計が、たとえばオニオンアーキテクチャを使用してアプリケーション層をドメイン層とマージする場合とは異なることを暗示しているかどうかはわかりません。
少なくともモジュールに関する限り、この 2 つは異なるべきではないと思います。どちらの場合も、アプリケーション層モジュールとドメイン層モジュールを分離できるからです。(告白しなければなりませんが、シャペロン モジュール (Evan の本) を飛ばしました。なぜなら、DDD を学ぶ初期段階でその知識が必要になるとは思わなかったからです :O )
2b)
はい。レイヤード アーキテクチャと対比できるからです。厳密なレイヤード アーキテクチャは、ドメイン レイヤーでリポジトリ インターフェイスを宣言し、インフラストラクチャ レイヤーで実装するという考えとは一致しません。これは、一方では依存関係がありますが、展開に関しては依存関係が他方にあるためです。Hexagonal は、ドメインを中心に配置することでこれらの問題に対処します。タマネギの構造を見てみましょう。基本的には六角形ですが、理解しやすいかもしれません。
私はまだMVCパターンまたはAsp.Net MVCを知りませんが、シリーズの最初の3つの部分を読んだことから（私はそれを読むのをやめたところまで混乱しました）、次のように見えます：
a）オニオンの記事から：
各レイヤーはその下のレイヤーに結合されており、各レイヤーは多くの場合、さまざまなインフラストラクチャの問題に結合されています。
著者は、従来のレイヤード アーキテクチャ TLA ではドメイン レイヤーがインフラストラクチャ レイヤーに結合されていることをほのめかしていますが、これは確かに正しくありません。通常、ドメイン レイヤー内でインフラストラクチャ インターフェイス(リポジトリ インターフェイスなど) を定義しているためです。
b) また、TLA を使用するときにアプリケーション層でインフラストラクチャ インターフェイスを定義することを決定した場合、アプリケーション層もインフラストラクチャ層に結合されませんか?!
c)インフラストラクチャ インターフェイスはアプリケーション コアで定義されているため、オニオン アーキテクチャでは * インフラストラクチャ レイヤー* がアプリケーション コア (アプリケーション レイヤーを含む) に結合されていませんか?
d) c)で「はい」の場合、アプリケーション レイヤーをインフラストラクチャ レイヤーに結合する方がよいのではないでしょうか(最初の質問で挙げた理由により (ここでは、ドメイン レイヤーはインフラストラクチャ サービスを呼び出さないと想定しています))。
4)
オニオンの記事から：
通常、ドメイン モデルの周りの最初の層は、リポジトリ インターフェイスと呼ばれる、オブジェクトの保存と取得の動作を提供するインターフェイスを見つける場所です。
オニオンの記事から：
コントローラーは、アプリケーション コアで定義されているインターフェイスのみに依存します。すべての依存関係が中心に向かっていることに注意してください。
著者は、依存関係は内部のみであり、インフラストラクチャ インターフェイスはドメイン モデルの周りで定義されているため、ドメイン モデル内のコードはこれらのインターフェイスを参照すべきではないことを暗示しているようです。言い換えれば、 Domain エンティティのメソッドへの引数としてリポジトリ参照を渡すべきではありません（あなた自身が言ったように許可されています）：
class Foo
{
...
public int DoSomething(IRepository repo)
{
...
var info = repo.Get...;
...
}
}
上記の理由により、私はOnion アーキテクチャを使用する利点や、それが TLA とどのように異なるのかさえ理解できていないことを告白しなければなりません (すべてのインフラストラクチャ インターフェイスがドメイン層内で定義されていると仮定します) --> 言い換えれば、TLA を描写できませんでしたか?オニオンのアーキテクチャ図を使用?!
最終更新:
2)
b)
はい。TLA では、ドメイン レイヤーは、インフラストラクチャ レイヤーによって宣言されたクラスに関して、インフラストラクチャと直接通信します。その逆ではありません。
念のために言っておきますが、TLA ではインフラストラクチャ インターフェイスがインフラストラクチャ レイヤーで定義されると言っているのですか(Hexagonal/Onion アーキテクチャではアプリケーション コアで定義されることはわかっています)。
d)
カップリングは双方向です。アプリケーション コアはインフラストラクチャの実装に依存し、インフラストラクチャはアプリケーション コアで宣言されたインターフェイスに依存します。
私のポイントは、Onion アーキテクチャではInfServインターフェースがアプリケーション層内で宣言されているためです (ここでは、InfServがドメイン層によって呼び出されることは決してないという前提があるため、ドメイン層内でInfServインターフェースを定義しないことにします– 元の1aの質問を参照してください)。は、アプリケーション層がInfServインターフェイスを制御することを意味します。しかし、元の2bに記載されている理由により、インフラストラクチャ レイヤーがInfServインターフェイスを制御した方がよいと私は主張します。質問？！
4)
著者は、依存関係は内部のみであり、インフラストラクチャ インターフェイスはドメイン モデルの周りで定義されているため、ドメイン モデル内のコードはこれらのインターフェイスを参照すべきではないことを暗示しているようです。
私の意見では、あなたのコード サンプルはコードに適しています。
したがって、オニオンアーキテクチャはドメインモデルがインフラストラクチャインターフェイスを参照することを「許可」していないと言ったのは正しかったです.DMストロングテキストを囲み、DMからそれらを参照することはその依存関係はDMからInDeに上向きになりますか?
DDD は通常、六角形/オニオン アーキテクチャ スタイルで表示されるため、混乱が生じる可能性があります。おそらくあなたがしていることはすでに六角形になっていると思います。それが同じことのように見える理由です。
ええ、私もその印象を受けました。Evan の本を読み終わったら、Hexagonal アーキテクチャをもう少し詳しく調べる予定です (特に、新しい DDD の本はそれに基づいているため)。
4 回目の更新:
2)
d)
インフラストラクチャがインターフェイスと実装を所有している場合、ドメインまたはアプリケーション層は、それ自体の永続性を実装する責任があります。
インフラストラクチャ層で定義されたインターフェースを参照すると、内側層が外側層に依存しないというオニオンのルールになるため、アプリケーションまたはドメイン層はそれを自分で実装する必要があると思います（インフラストラクチャ層は外側層です）？
4)
ドメイン モデルは、一緒に宣言されているため、リポジトリなどのインフラストラクチャ インターフェイスを参照できます。オニオン ダイアグラムのように、アプリケーション層がドメインから分離されている場合、ドメイン層はアプリケーション層で定義できるため、インターフェイスの参照を回避できます。
しかし、その記事によると、インフラストラクチャ インターフェイスはDomain Layerを囲むレイヤーで宣言されています。これは、 Domain Layerよりもアプリケーション コアの外縁に近いことを意味します。記事で指摘されているように、内側のレイヤーには依存関係があってはなりません。外層＞！
ありがとうございました