다음을 통해 공유


마이크로 서비스 애플리케이션 계층 및 Web API 디자인

팁 (조언)

이 콘텐츠는 .NET Docs 또는 오프라인으로 읽을 수 있는 다운로드 가능한 무료 PDF로 제공되는 컨테이너화된 .NET 애플리케이션용 .NET 마이크로 서비스 아키텍처인 eBook에서 발췌한 내용입니다.

컨테이너화된 .NET 애플리케이션을 위한 .NET 마이크로서비스 아키텍처 eBook의 표지 썸네일.

SOLID 원칙 및 종속성 주입 사용

SOLID 원칙은 DDD 패턴을 사용하여 마이크로 서비스를 개발하는 것과 같이 모든 최신 및 중요 업무용 애플리케이션에서 사용되는 중요한 기술입니다. SOLID는 5가지 기본 원칙을 그룹화한 약어입니다.

  • 단일 책임 원칙

  • 개방형/닫힌 원칙

  • 리스코프 대체 원칙

  • 인터페이스 분리 원칙

  • 종속성 반전 원칙

SOLID는 애플리케이션 또는 마이크로 서비스 내부 계층을 디자인하는 방법과 이러한 계층 간의 종속성을 분리하는 방법에 대해 자세히 설명합니다. 도메인이 아니라 애플리케이션의 기술 디자인과 관련이 있습니다. 종속성 반전 원칙의 최종 원칙을 사용하면 인프라 계층을 나머지 계층과 분리할 수 있으므로 DDD 계층의 더 나은 분리된 구현이 가능합니다.

DI(종속성 주입)는 종속성 반전 원칙을 구현하는 한 가지 방법입니다. 개체와 해당 종속성 간의 느슨한 결합을 달성하기 위한 기술입니다. 공동 작업자를 직접 인스턴스화하거나 정적 참조(즉, new...를 사용)를 사용하는 대신 해당 작업을 수행하기 위해 클래스에 필요한 개체가 클래스에 제공되거나 "삽입"됩니다. 대부분의 경우 클래스는 생성자를 통해 해당 종속성을 선언하므로 명시적 종속성 원칙을 따를 수 있습니다. 종속성 주입은 일반적으로 특정 IoC(Inversion of Control) 컨테이너를 기반으로 합니다. ASP.NET Core는 간단한 기본 제공 IoC 컨테이너를 제공하지만 Autofac 또는 Ninject와 같은 즐겨 찾는 IoC 컨테이너를 사용할 수도 있습니다.

SOLID 원칙에 따라 클래스는 자연스럽게 작고, 잘 고려되고, 쉽게 테스트되는 경향이 있습니다. 그러나 너무 많은 종속성이 클래스에 주입되는지 어떻게 알 수 있습니까? 생성자를 통해 DI를 사용하는 경우 생성자에 대한 매개 변수 수를 확인하면 이를 쉽게 감지할 수 있습니다. 종속성이 너무 많은 경우 이는 일반적으로 클래스가 너무 많은 작업을 수행하려고 하는 기호( 코드 냄새)이며 단일 책임 원칙을 위반할 수 있습니다.

SOLID를 자세히 설명하기 위해 또 다른 가이드가 필요합니다. 따라서 이 가이드에서는 이러한 항목에 대한 최소한의 지식만 있으면 됩니다.

추가 리소스