책너두 (도메인 주도 설계로 시작하는 마이크로서비스 개발) 15일차 (~128p)

요약

• 5장. 마이크로서비스 설계 나머지 부분에 대해 이해함.
  • 마이크로서비스를 도출하는 방법
    • DDD의 바운디드 컨텍스트 기반 도출
  • DDD에서의 설계
  • DDD의 전략적 설계
    • 도메인과 서브도메인
    • 유비쿼터스 언어와 도메인 모델, 바운디드 컨텍스트
    • 컨텍스트 매핑
      • 주요 컨텍스트 매핑 관계

메모

5.1.2 DDD의 바운디드 컨텍스트 기반 도출

• 마이크로서비스는 독립적인 저장소를 가지며, 서로 직접 참조하지 않는 특성이 있음.
  • 이는 독립적으로 수정 및 배포 가능한 서비스를 가능하게 함.
  • 서비스 도출 시, 각 서비스가 소유하는 데이터를 독립적으로 식별하는 것이 중요함.
• 기능 분해 방식은 데이터 식별에 적합하지 않고, 기능과 데이터가 분리되는 경향이 있음.
  • 이로 인해 하나의 통합 데이터가 여러 기능에서 사용되는 모델링이 발생함.
• 반면에, DDD(Domain-Driven Design)는 데이터를 기능과 분리해서 식별하지 않음.
  • 각 하위 도메인마다 별도의 '도메인 모델'을 정의하며, 이는 각 업무에 특화된 유비쿼터스 언어로 정의됨.
  • 이로 인해, 업무에 특화된 개념이 구성됨.
• DDD의 이런 특성은 마이크로서비스의 자율적인 개발 및 운영과 잘 어울림.
  • 따라서 도메인 모델을 소유한 '바운디드 컨텍스트' 중심으로 마이크로서비스를 도출하는 가이드로 사용될 수 있음.

5.2 DDD에서의 설계

• 클라우드와 마이크로서비스 아키텍처를 적용하면 독립적 개선과 배포, 장애 격리, 빠른 재실행 등의 장점을 얻을 수 있음.
  • 이를 가능하게 하기 위해, 마이크로서비스를 응집성 있게 식별하는 것이 중요함.
• DDD의 전략적 설계에서는 비즈니스 응집성이 있는 컨텍스트를 바운디드 컨텍스트로 구분하며, 이 단위가 마이크로서비스 식별에 적합함.
  • 또한 식별된 마이크로서비스의 내부 구조를 정의하고 설계하기 위해 DDD의 전술적 설계를 사용할 수 있음.
• 비즈니스 변화에 빠르게 대응하기 위해 클라우드와 마이크로서비스 아키텍처를 적용하는 경우, 비즈니스 변화에 못지 않게 빠르게 변화하는 구현 기술에 대응할 수 있는 유연한 애플리케이션 아키텍처가 필요함.
  • 이를 위해, DDD의 전술적 설계가 기술 변화에 유연한 애플리케이션 구조를 설계하는 기법을 제공함.

5.3 DDD의 전략적 설계

5.3.1 도메인과 서브도메인

• DDD의 전략적 설계는 복잡한 비즈니스 도메인을 논리적으로 구분된 여러 개의 하위 영역으로 나누는 기법임.
  • 이렇게 분리된 하위 도메인을 서브도메인이라고 함.
  • 서브도메인은 중요도에 따라 핵심 서브도메인, 지원 서브도메인, 일반 서브도메인의 세 가지 유형으로 나뉨.
• 핵심 서브도메인은 경쟁자와 차별화를 만들 비즈니스 영역으로, 프로젝트 목록에서 높은 우선순위를 가지며 소프트웨어 개발에서 가장 큰 투자가 필요한 영역임.
  • 지원 서브도메인은 비즈니스에 필수적이지만 핵심은 아닌 부분으로, 핵심 도메인을 성공시키기 위해서는 반드시 필요한 영역임.
  • 일반 서브도메인은 비즈니스적으로 특화된 부분은 아니지만 전체 비즈니스 솔루션에는 필요한 부분으로, 기존 제품을 구매해서 대체할 수 있음.
• 아마존은 추천 영역을 핵심 서브도메인으로 정하고 차별화를 위해 더 많은 역량을 투입했을 것임.
  • 쿠팡은 로켓배송 영역을 핵심 서브도메인으로 선정하여 전략적인 투자를 통해 차별화된 배송 전략으로 성공했을 것임.
• 전략적 설계는 마이크로서비스를 도출하는 방법이자 비즈니스상 전략적으로 중요한 것을 찾아 중요도에 따라 일을 나누는 방법임.
  • 이를 위해 알아야 할 중요한 개념 두 가지는 바운디드 컨텍스트와 유비쿼터스 언어임.
  • 바운디드 컨텍스트는 도메인의 주요 개념을 정의하고 도메인 간의 경계를 식별하는 것이며, 유비쿼터스 언어는 도메인의 모든 구성원이 공통으로 사용하는 언어임.

5.3.2 유비쿼터스 언어와 도메인 모델, 바운디드 컨텍스트

• 유비쿼터스 언어는 특정 도메인의 의도와 핵심 개념을 명확하게 전달하는 언어를 의미함.
  • 이 언어를 사용하면 고객, 설계자, 개발자 모두 같은 용어를 사용해 오해를 없앨 수 있음.
  • 유비쿼터스 언어는 특정 도메인의 세부적인 업무 개념을 표현하는 언어로, 예를 들어 결제 도메인에서의 '고객'과 배송 도메인에서의 '고객'은 서로 다른 의미를 가짐.
• 도메인 모델은 특정 비즈니스 맥락에서 사용되는 개념들의 관계를 잘 정의한 모형임.
  • 도메인 모델을 보면 해당 비즈니스를 이해할 수 있어야 함.
  • 도메인 모델은 도메인과 관련된 업무를 수행하는 모든 구성원들이 이해하는 기본 모형이 됨.
• 바운디드 컨텍스트는 도메인 모델과 다른 도메인 모델 간의 경계를 나타내며, 이 경계는 해당 도메인의 언어와 개념을 정의함.
  • 바운디드 컨텍스트는 도메인 모델을 원으로 표현하여 나타냄.
• 소스코드에서도 유비쿼터스 언어가 사용되어야 하며, 새로운 팀원이 이를 이해하고 도메인 전문가와 의사소통할 수 있어야 함.
  • 이렇게 하면 도메인과 서비스에 대한 동일한 비전을 공유하고, 서비스는 지속적으로 개발, 유지될 수 있음.
  • 이러한 특성이 DDD와 마이크로서비스가 잘 어울리는 점임.

5.3.3 컨텍스트 매핑

• 바운디드 컨텍스트를 식별하며, 내부적으로 응집성이 높고, 다른 컨텍스트와는 의존관계가 낮아야 함.
  • 그러나 컨텍스트 간에는 연계가 필요하며, 이를 컨텍스트 매핑이라 함.
  • 이 매핑은 컨텍스트 맵을 통해 표현되며, 다양한 매핑 패턴을 이해해야 함.

주요 컨텍스트 매핑 관계

• 공유 커널(Shared Kernel)
  • 공통적인 모델을 공유하는 관계를 나타낸다. 공유 커널은 팀 간의 공통 모델 합의를 필요로 함
• 소비자와 공급자(Customer-Supplier)
  • 상류와 하류 관계로, 데이터의 흐름은 상류에서 하류로 이루어짐.
  • 상류의 변화는 하류에서 따라가야 함.
• 준수자(Confirmist)
  • 상류 팀이 하류 팀의 요구를 지원하지 않거나 못하는 경우 사용됨.
  • 하류팀은 상류팀의 모델을 그대로 사용함.
• 충돌 방지 계층(ACL; Anti-Corruption Layer)
  • 하류 팀의 모델을 보호하기 위한 번역 계층을 구성하는 것임.
    • 이 계층은 하류 모델의 독립성을 유지하면서 데이터를 변환하는 메커니즘을 구현함.
  • 이 매핑 유형은 클라우드 기반의 마이크로서비스 아키텍처에서 레거시 시스템과 통합할 때 주로 사용됨.
• 공개 호스트 서비스(OHS; Open Host Service)
  • 바운디드 컨텍스트에 대한 접근을 제공하는 프로토콜이나 인터페이스를 정의함.
• 발행된 언어(PL; Published Language)
  • 하류 컨텍스트가 상류 컨텍스트의 기능을 사용하게 하기 위한 문서화된 정보 교환 언어를 의미함.
    • 주로 공개 호스트 서비스와 함께 사용됨.