[MSA] 도메인 주도 설계(Domain-Driven Design - DDD)

이 글은 '샘 뉴먼 - 마이크로소프트 아키텍처 구축' 내용을 기반으로 합니다.

 

DDD(도메인 주도 설계)는 현실 세계의 도메인을 코드로 표현하는 것의 중요성을 강조하고, 이를 바탕으로 시스템을 더 효과적으로 모델링하는 방법이다. 마이크로서비스 아키텍처 설계 시 DDD 원칙을 적용하면, 각 서비스가 명확한 책임을 가지고 독립적으로 발전할 수 있는 기반을 마련할 수 있다. 특히, DDD에서 가장 중요한 것은 경계 컨텍스트(Bounded Context) 를 사용하여 서비스 경계를 정의하는 것이다.

• 경계 컨텍스트 (Bounded Context): 특정 도메인은 여러 개의 경계 컨텍스트로 구성된다. 각 컨텍스트는 자신만의 모델과 언어(Ubiquitous Language)를 가지며, 다른 컨텍스트와는 명확히 구분된다. 예를 들어, 온라인 뮤직 스토어(MusicCorp)에서 재고 관리(Inventory) 와 주문 처리(Ordering) 는 별도의 경계 컨텍스트이다.
• 서비스 경계: 마이크로서비스의 경계는 이러한 경계 컨텍스트와 일치시키는 것이 이상적이다. 이는 서비스 내의 높은 응집도(High Cohesion) 와 서비스 간의 느슨한 결합(Loose Coupling) 을 달성하는 데 핵심적이다.
• 명시적 인터페이스 / 내부 구현 은닉: 각 컨텍스트(서비스)는 외부에 제공할 기능과 데이터를 명시적인 인터페이스(API 또는 코드 상의 Interface) 를 통해 정의하고, 내부의 복잡한 모델이나 로직, 데이터 저장 방식 등은 외부로부터 숨겨야(은닉) 한다. 이는 한 서비스의 내부 변경이 다른 서비스에 미치는 영향을 최소화한다.
• 비즈니스 능력 중심 모델링: 서비스는 특정 비즈니스 능력(Business Capability) 을 중심으로 설계되어야 한다. 데이터 CRUD 기능 노출보다는, 특정 비즈니스 문제를 해결하는 행위(동사) 중심으로 인터페이스를 설계하는 것이 좋다.
• 점진적 분해: 모놀리식 시스템에서 시작하여, DDD 원칙에 따라 내부 모듈 경계를 명확히 하고 점진적으로 마이크로서비스로 분리하는 것이 효과적이다.