たとえば、2 つのサービスを必要とするアプリケーションがあるとします。Application、Service1、Service2
このオニオン アーキテクチャに従って、余分なレベルの間接化を構築し、サービスの 1 つをアプリケーション サービスに昇格させ、もう 1 つをドメイン サービスに降格させる必要があります。
または、 と の両方に直接接続する必要がありApplicationますか?Service1Service2
別のレベルの間接化を使用すると、Applicationレイヤーへの依存、特に外部サービスへの依存を減らすことができます。「Paypal」、「Facebook」、「CyberSource」を使用して、プログラミング パラダイムにより適したアプリケーション サービス アダプターを作成します。結局、すべての開発者がこれらの多種多様な API に慣れ親しんでいることは、生産性にとって非常に有害です。ファサード/アダプタは、アプリケーションをインフラストラクチャの変更から保護しながら、開発を容易にします。例えば。同社は CyberSource で失敗し、代わりに Paypal を使用することにしました。幸いなことに、アプリケーションはシールドされており、アダプターを変更するだけで済み、他には何も必要ありませんでした。
とはいえ、アダプターは間違いなく柔軟性を失います。アプリケーションが複雑になるにつれて、アダプターもリークしやすくなります。次に、潜在的に 3 つの問題があります: 漏れやすい抽象化、怠惰なレイヤー (穴が多すぎるために十分に機能していないレイヤー)、および一般的な閉鎖原則の違反です。UI を変更する必要があるときはいつでも、アプリケーションだけでなく、アダプタも。
そしてService2、同じ会社内ですでに内部サービスになっている場合はどうなりますか? サブシステムごとにアダプターを作成する必要がありますか? あなたのチームが小さい場合はどうなりますか？多様なテクノロジー セットを備えたチームが数十ある場合はどうなるでしょうか。別の間接レイヤーを追加することと、単にサービスを直接呼び出すことの妥当性についてのガイダンスはありますか?