ファサードレイヤーに何を配置する必要があるか、およびファサードレイヤーが下にあるレイヤーに対して何回呼び出す必要があるかについて「ディスカッション」を行っています。
私たちのプロジェクトには、サービスとデータベースへの呼び出しを調整するオーケストレーションレイヤーがあります。また、ビジネスルールと計算を備えたビジネスレイヤーもあります。
私たちのファサードレイヤーには、セキュリティチェック、ロギング、エラー処理があります。
ここで、質問：ファサードにオーケストレーションレイヤーへの呼び出しが1つしかないのか、それとも複数の呼び出しで問題ないのか。単一の呼び出しのみの場合、これらのレイヤーを単一のレイヤーにマージする必要があります。
これらはC＃で記述されたWCFサービスです。
ファサード内の呼び出しの数は、呼び出しが（呼び出し元の目から見て）単一の操作を実行し、それを完全に実行する限り、重要ではありません。
呼び出し元への単一の操作には、ロギング、ビジネスルールの実行、データベースへの接続のオープン、データベースへの書き込み、そして最後に接続のクローズとクリーンアップが含まれる場合があることに注意してください。
私はジャスティンの答えを支持しますが、それには1つだけ考慮事項を追加します。オーケストレーションレイヤーがビジネスレイヤーも処理し、ファサードがオーケストレーションタスクへの1対1のマップになる場合は、オーケストレーションをファサードにすることを検討できます。ただし、この場合は質問しないので、ファサードがオーケストレーションの使用プロトコルを単純化しているか、オーケストレーションとビジネスレイヤーがピアです。いずれの場合も、オーケストレーションモジュールとは異なるファサードが必要です
単一の呼び出しのみの場合、これらのレイヤーを単一のレイヤーにマージする必要があります。
ファサードレイヤーとオーケストレーションレイヤーは緩く結合されていますか？もしそうなら、私の答えは「いいえ」です。マージしないでください。原則の観点からすると、緩い結合には価値があり、それを維持する必要があると思います。
ファサードにオーケストレーションレイヤーへの呼び出しが1つしかない場合、または複数の呼び出しで問題ない場合。
複数の呼び出しを行った瞬間、それが実行していることとオーケストレーションレイヤーが実行していることの違いは何ですか。彼らの生きる理由を考えてください。
ただし、純粋に「ビジネス」コールと「クロスカッティング」コールを区別することはできます。1つの「ビジネス」コールのみがファサードを「通過」できるという規則を確立することにより、ビジネスサービスへのクリーンな構造を維持します（混乱はありません）。しかし一方で、システムの動作と機能を強化する他の横断的な呼び出しを行うことから技術的に制約されていません。