リポジトリ レイヤー (永続性)、サービス レイヤー (アプリケーション)、および Web (UI) レイヤーを備えた Web アプリケーションを考えてみましょう。
UI コンポーネントではなく、サービスまたはリポジトリ レイヤーのコンポーネントに依存しないコンポーネント (つまり、ExternalProgramExecutor) を検討してください。
質問は次のとおりです。
次の質問を自問してください。
最初の質問に対する答えは「いいえ」です。なぜなら、コンポーネントはアプリケーションにまったくフックされていないことをすでにおっしゃっていたからです。
2 番目の質問に対する答えは「はい」です。これは、すべての優れたソフトウェア コンポーネントが提供するものであり、何らかのサービスです。
しかし、それに値する柔軟なコンポーネントは、ソフトウェア アプリケーションのほぼどこでもうまく動作するはずです。したがって、本当の問題は次のとおりです。Web アーキテクチャが最も忠実に維持されるように、コンポーネントをどこに配置すればよいでしょうか?
結局のところ、Web アーキテクチャーは組織的なメカニズムにすぎません。The One True Web Architecture Reference™ で答えを見つけようとしているのなら、それは間違って います。
個人的には、@Robert が尋ねた質問のリストに別の質問を追加します。
私は通常、新しいユーティリティ/フレームワーク コンポーネントをアーキテクチャに追加します。これは、後で他のアプリケーションで再利用できる完全に独立したコンポーネントを配置する場所です。
DDDによると、この種のサービス (「ユーティリティ/ヘルパー」サービスに同化できるように思われる) は、「インフラストラクチャ レイヤー」にあるはずです (出典: InfoQ ) 。
建築
一般的なエンタープライズ アプリケーション アーキテクチャは、次の 4 つの概念層で構成されます。
- ユーザー インターフェイス(プレゼンテーション レイヤー): ユーザーに情報を提示し、ユーザー コマンドを解釈する役割を担います。
- アプリケーション層: この層は、アプリケーション アクティビティを調整します。ビジネスロジックは含まれていません。ビジネス オブジェクトの状態は保持しませんが、アプリケーション タスクの進行状態を保持できます。
- ドメイン レイヤー: このレイヤーには、ビジネス ドメインに関する情報が含まれます。ビジネス オブジェクトの状態がここに保持されます。ビジネス オブジェクトの永続性と、場合によってはその状態は、インフラストラクチャ レイヤーに委任されます。
- インフラストラクチャ レイヤー: このレイヤーは、他のすべてのレイヤーのサポート ライブラリとして機能します。レイヤー間の通信を提供し、ビジネス オブジェクトの永続性を実装し、ユーザー インターフェイス レイヤーをサポートするライブラリを含みます。
「インフラストラクチャ層」の一部になることを願っています。見てください：
http://en.wikipedia.org/wiki/Common_layers_in_an_information_system_logical_architecture
ありがとう。
アプリケーションExternalProgramExecutorはこれを外部コンポーネントとして使用するため、それ自体がサービスです。
明らかに、アプリケーションのプロジェクトの一部としてそのコンポーネントを配置しない場合、そのサービスをアプリケーションに配置することはできません。source codeしたがって、実際にはGateway、プロジェクトでそのサービス/コンポーネントを超えることになります。それを作成するためにSOLID、ゲートウェイは抽象になり、質問はその抽象ゲートウェイをどこから参照する必要があるかです。
答えは、ExternalProgramExecutor (したがってゲートウェイ) によって提供される機能の種類と、プロジェクトがその機能をどのように使用しているかによって完全に異なります。抽象機能はレイヤーの一部ではありませんが、アプリケーションの最上層から最下層 (DAL -> ... -> UI) に移動します。適切なレイヤーを見つけたら、そのレイヤーでゲートウェイを使用します。最下層は、実行時に具体的なゲートウェイの存在を認識しないようにする必要があります。
概念的には、「ExternalProgramExecutor」はサービスのように見えるため、サービス層に属します。
サービス層の詳細に進むには、次の 2 つの可能性があります。
この選言は、より実用的な観点 (実装) にとどまります。