アプリケーション層はDDDのインフラストラクチャ層に依存する必要がありますか？

Question

私はアプリケーションサービスがオーケストレーションに使用されていることを読んで、アプリケーションのワークフローを処理します。

例：ユーザーAからユーザーBに送金した後、システムはメールを送信する必要があります。

したがって、アプリケーションサービスは、ドメインエンティティ、ドメインサービスを呼び出してドメインロジックを処理します。インフラストラクチャを呼び出して電子メールを送信します。アプリケーション層は、ドメイン層とインフラストラクチャ層に依存します。 DDDに違反していますか？アプリケーション層はDDDのインフラストラクチャ層に依存する必要がありますか？

Answer 1

アプリケーション層はDDDのインフラストラクチャ層に依存する必要がありますか？

あなたが探しているパターンは「サービスプロバイダ」だと思います。

アプリケーションコンポーネントが独自の責任を果たすために満足を必要とすることインタフェース/ API /契約を定義し

インフラストラクチャコンポーネントは、このインタフェースの実装を提供

合成ルートは、インフラストラクチャ・コンポーネントを作成し、そしてそれを使用してアプリケーションコンポーネントを作成します。

アプリケーションの自動テストでは、おそらくドメインコンポーネントを含めることになりますが、インフラストラクチャコンポーネントをテストダブルに置き換えます。

Answer 2

一般的に、階層化されたアーキテクチャを考えるとき、厳密なアーキテクチャと緩やかな階層化されたアーキテクチャの区別があります。

リラックスしたレイヤーアプローチでは、レイヤーはすぐ下にあるレイヤーだけでなく、すべての下位レイヤーにアクセスすることが許可されています（厳密なアプローチとなります）。

私の個人的な意見では、中継されたアプローチは麻酔であり、DDDでは完全に問題ありません.1つは層と独断的ではありません。

たとえば、リラックスしたアプローチを決め、それを記述したとおりに使用します。アプリケーションサービスからは、ドメイン層のビルディングブロックとインフラストラクチャコンポーネント（電子メールなどの通知用）を利用して、用途を調整します。

PS：これはDDDに違反する場合の一般的な説明と同じです。もちろん、戦略パターンでDIを使ってレイヤーの密結合を防ぐ必要があります...

Answer 3

私はDDDの原則に違反するとは思わないが、私はDDDの純粋さではないので、わからない。

おそらくこれは有用であり得る：http://dddsample.sourceforge.net/architecture.html

「3つの垂直層に加えて、インフラもある画像が示すように、それとの間の通信を容易にする、さまざまな方法で三層の全てをサポートします。層。 "

電子メールサービスは外部サービスと見なされ、インフラストラクチャに属していると思います。