하위 도메인으로 분해

패턴: 하위 도메인으로 분해

문맥

크고 복잡한 애플리케이션을 개발 중이며 마이크로서비스 아키텍처 를 사용하려고 합니다 . 마이크로서비스 아키텍처는 느슨하게 결합된 서비스 세트로 애플리케이션을 구성합니다. 마이크로서비스 아키텍처의 목표는 지속적인 전달/배포를 가능하게 하여 소프트웨어 개발을 가속화하는 것입니다.

마이크로서비스 아키텍처는 두 가지 방식으로 이를 수행합니다.

1. 테스트를 단순화하고 구성 요소를 독립적으로 배포할 수 있습니다.
2. 엔지니어링 조직을 소규모(6-10명의 구성원)의 자율적인 팀 모음으로 구성하며, 각 팀은 하나 이상의 서비스를 담당합니다.

이러한 혜택은 자동으로 보장되지 않습니다. 대신 애플리케이션을 서비스로 조심스럽게 기능적으로 분해해야만 달성할 수 있습니다.

서비스는 소규모 팀에서 개발하고 쉽게 테스트할 수 있을 만큼 작아야 합니다. 객체 지향 설계(OOD)의 유용한 지침은 단일 책임 원칙( SRP )입니다. SRP는 클래스의 책임을 변경 사유로 정의하고 클래스는 변경 사유가 하나만 있어야 한다고 명시하고 있습니다. SRP를 서비스 디자인에도 적용하고 응집력이 있고 강력하게 관련된 작은 기능 세트를 구현하는 서비스를 디자인하는 것도 이치에 맞습니다.

또한 대부분의 새롭고 변경된 요구 사항이 단일 서비스에만 영향을 미치도록 응용 프로그램을 분해합니다. 여러 서비스에 영향을 미치는 변경 사항에는 여러 팀 간의 조정이 필요하므로 개발 속도가 느려집니다. OOD의 또 다른 유용한 원칙은 동일한 이유로 변경되는 클래스는 동일한 패키지에 있어야 한다는 CCP(Common Closure Principle)입니다. 예를 들어, 두 클래스가 동일한 비즈니스 규칙의 다른 측면을 구현합니다. 목표는 해당 비즈니스 규칙이 개발자를 변경할 때 적은 수의 패키지(이상적으로는 하나의 패키지)에서만 코드를 변경하는 것입니다. 이러한 종류의 생각은 각 변경 사항이 하나의 서비스에만 영향을 미치도록 하는 데 도움이 되므로 서비스를 설계할 때 의미가 있습니다.

문제

애플리케이션을 서비스로 분해하는 방법은 무엇입니까?

힘

• 아키텍처는 안정적이어야 합니다.
• 서비스는 응집력이 있어야 합니다. 서비스는 강력하게 관련된 기능의 작은 집합을 구현해야 합니다.
• 각 변경 사항이 하나의 서비스에만 영향을 미치도록 서비스는 공통 폐쇄 원칙(함께 변경되는 사항은 함께 패키징되어야 함)을 준수해야 합니다.
• 서비스는 느슨하게 결합되어야 합니다. 각 서비스는 구현을 캡슐화하는 API입니다. 클라이언트에 영향을 주지 않고 구현을 변경할 수 있습니다.
• 서비스는 테스트 가능해야 합니다.
• 각 서비스는 "2개의 피자" 팀, 즉 6-10명으로 구성된 팀이 개발할 만큼 충분히 작습니다.
• 하나 이상의 서비스를 소유한 각 팀은 자율적이어야 합니다. 팀은 다른 팀과의 최소한의 협업으로 서비스를 개발하고 배포할 수 있어야 합니다.

해결책

DDD(Domain-Driven Design) 하위 도메인에 해당하는 서비스를 정의합니다. DDD는 응용 프로그램의 문제 공간(비즈니스)을 도메인으로 나타냅니다. 도메인은 여러 하위 도메인으로 구성됩니다. 각 하위 도메인은 비즈니스의 다른 부분에 해당합니다.

하위 도메인은 다음과 같이 분류할 수 있습니다.

• 핵심 - 비즈니스의 핵심 차별화 요소이자 애플리케이션의 가장 중요한 부분
• 지원 - 비즈니스가 하는 일과 관련되지만 차별화 요소는 아닙니다. 이는 사내에서 구현하거나 아웃소싱할 수 있습니다.
• 일반 - 비즈니스에 국한되지 않으며 기성품 소프트웨어를 사용하여 이상적으로 구현됩니다.

예

온라인 상점의 하위 도메인은 다음과 같습니다.

• 제품 카탈로그
• 재고 관리
• 주문 관리
• 배송 관리
• …

해당 마이크로 서비스 아키텍처에는 이러한 각 하위 도메인에 해당하는 서비스가 있습니다.

결과 컨텍스트

이 패턴에는 다음과 같은 이점이 있습니다.

• 하위 도메인이 상대적으로 안정적이므로 안정적인 아키텍처
• 개발 팀은 기능이 교차되고 자율적이며 기술적 기능보다는 비즈니스 가치를 제공하는 데 중점을 두고 조직됩니다.
• 서비스가 응집력 있고 느슨하게 결합됨

문제

해결해야 할 문제는 다음과 같습니다.

• 하위 도메인을 식별하는 방법은 무엇입니까? 하위 도메인 및 서비스를 식별하려면 비즈니스에 대한 이해가 필요합니다. 비즈니스 기능과 마찬가지로 하위 도메인은 비즈니스 및 조직 구조를 분석하고 다양한 전문 분야를 식별하여 식별됩니다. 하위 도메인은 반복 프로세스를 사용하여 가장 잘 식별됩니다. 하위 도메인을 식별하기 위한 좋은 출발점은 다음과 같습니다.

• 조직 구조 - 조직 내의 다른 그룹이 하위 도메인에 해당할 수 있음

• 상위 수준 도메인 모델 - 하위 도메인에는 종종 키 도메인 개체가 있습니다.

• Decompose by 비즈니스 기능 패턴은 대체 패턴입니다 .

https://microservices.io/patterns/decomposition/decompose-by-subdomain.html