次の方法で共有


マイクロサービス アプリケーション レイヤーと Web API を設計する

ヒント

このコンテンツは、.NET Docs で入手できる、またはオフラインで読み取ることができる無料のダウンロード可能な PDF として入手できる、コンテナー化された .NET アプリケーションの電子ブックである .NET マイクロサービス アーキテクチャからの抜粋です。

コンテナー化された .NET アプリケーションの .NET マイクロサービス アーキテクチャの電子ブックの表紙サムネイル。

SOLID原則と依存性注入を用いる

SOLID 原則は、DDD パターンを使用したマイクロサービスの開発など、最新のミッション クリティカルなアプリケーションで使用される重要な手法です。 SOLID は、5 つの基本的な原則をグループにする頭字語です。

  • 単一責任の原則

  • オープン/クローズの原則

  • Liskov 置換の原則

  • インターフェイス分離の原則

  • 依存関係反転の原則

SOLID は、アプリケーションまたはマイクロサービスの内部レイヤーを設計する方法と、それらの間の依存関係を分離する方法について詳しく説明します。 ドメインではなく、アプリケーションの技術的な設計に関連しています。 最後の原則である依存関係反転の原則を使用すると、インフラストラクチャ レイヤーを他のレイヤーから切り離すことができます。これにより、DDD レイヤーのより適切に分離された実装が可能になります。

依存関係の挿入 (DI) は、依存関係反転の原則を実装する 1 つの方法です。 これは、オブジェクトとその依存関係の間の疎結合を実現するための手法です。 コラボレーターを直接インスタンス化したり、静的参照 (つまり new.... を使用) を使用したりするのではなく、そのアクションを実行するためにクラスに必要なオブジェクトがクラスに提供されます (または、"挿入")。 ほとんどの場合、クラスはコンストラクターを介して依存関係を宣言し、明示的な依存関係の原則に従うことができます。 依存性注入は、通常、特定の制御の反転 (IoC) コンテナに基づいています。 ASP.NET Core には単純な組み込みの IoC コンテナーが用意されていますが、Autofac や Ninject などのお気に入りの IoC コンテナーを使用することもできます。

SOLID 原則に従うことで、クラスは自然に小さく、十分に考慮され、簡単にテストされる傾向があります。 しかし、あまりにも多くの依存関係がクラスに挿入されているかどうかをどのように知ることができますか? コンストラクターで DI を使用する場合は、コンストラクターのパラメーターの数を見るだけで簡単に検出できます。 依存関係が多すぎる場合、これは一般的にはクラスがやりすぎようとしていることの兆候(コードの悪臭)であり、単一責任の原則に違反している可能性があります。

SOLIDについて詳しく説明するには、別のガイドが必要です。 したがって、このガイドでは、これらのトピックに関する最小限の知識のみを持っている必要があります。

その他のリソース