-
소프트웨어 아키텍처 시리즈 16화 – 마이크로서비스 경계 설계와 바운디드 컨텍스트 적용 전략기술과 산업/아키텍처 2025. 8. 14. 17:20728x90
마이크로서비스 아키텍처에서 경계 설계는 성공과 실패를 가르는 핵심 요소입니다. 이번 글에서는 DDD의 바운디드 컨텍스트 개념을 기반으로, 서비스 경계를 올바르게 설정하는 실전 전략을 소개합니다.
왜 경계 설계가 중요한가?
마이크로서비스의 핵심은 작고 독립적인 서비스입니다.
하지만 “작다”는 것은 단순히 코드 라인이 적다는 뜻이 아니라, 명확한 비즈니스 책임을 가진다는 의미입니다.
잘못된 경계 설계는 다음과 같은 문제를 만듭니다:
- 서비스 간 데이터 공유와 의존성이 과도하게 발생
- 배포/변경이 다른 서비스에 파급
- 마이크로서비스가 오히려 “분산 모놀리식”으로 변질
바운디드 컨텍스트(Bounded Context)란?
DDD에서 바운디드 컨텍스트는 특정 도메인 모델이 유효하게 적용되는 경계를 의미합니다.
- 각 컨텍스트 안에서는 **유비쿼터스 언어(Ubiquitous Language)**가 일관되게 사용
- 컨텍스트 밖에서는 모델 의미가 변하거나, 다른 해석이 필요할 수 있음
즉, 바운디드 컨텍스트는 도메인 경계를 명확히 하여,
모델의 혼란과 오염을 방지하는 개념입니다.
바운디드 컨텍스트와 마이크로서비스의 관계
- 이상적인 경우: 하나의 바운디드 컨텍스트 = 하나의 마이크로서비스
- 현실적인 경우: 하나의 컨텍스트가 여러 마이크로서비스로 분할될 수도 있음 (규모나 비즈니스 복잡도에 따라)
경계 설계 절차 (실전 접근)
1. 도메인 분석
- 비즈니스의 핵심 기능과 하위 기능 나열
- 업무 용어, 규칙, 데이터 흐름 파악
2. 서브도메인 분류
- 핵심(Core) 도메인: 비즈니스 경쟁력의 핵심 로직
- 지원(Supporting) 도메인: 핵심을 보조하는 기능
- 일반(Generic) 도메인: 범용 솔루션으로 대체 가능
3. 바운디드 컨텍스트 정의
- 각 도메인별 모델 경계와 용어집(Ubiquitous Language) 설정
- 경계 내 모델과 로직은 다른 컨텍스트와 공유하지 않음
4. 서비스 경계 매핑
- 각 컨텍스트를 독립 서비스로 매핑
- 컨텍스트 간 통신 방식(Event, API 등) 정의
예시 – 전자상거래 도메인
바운디드 컨텍스트주요 기능마이크로서비스 예시
주문(Order) 주문 생성/취소, 상태 변경 Order Service 결제(Payment) 결제 승인, 결제 취소, 영수증 발급 Payment Service 재고(Inventory) 재고 확인, 입출고 관리 Inventory Service 배송(Shipping) 배송 요청, 추적, 반품 처리 Shipping Service
컨텍스트 간 관계 패턴
- 파트너십(Partnership)
- 두 컨텍스트가 긴밀하게 협력
- 예: 주문(Order) ↔ 결제(Payment)
- 공개 호스트 서비스(Open Host Service)
- 하나의 컨텍스트가 표준 API를 제공
- 예: 배송(Shipping)이 API로 추적 서비스 제공
- 발행-구독(Publish-Subscribe)
- 이벤트 기반 통신
- 예: 주문 완료 이벤트 → 재고 차감, 결제 요청
헥사고날 아키텍처와의 연결
- 각 마이크로서비스 내부 구조는 헥사고날 아키텍처로 구성 가능
- Inbound Port: 외부 요청(API, 이벤트) 수신
- Outbound Port: 다른 서비스 호출, 이벤트 발행
- 경계 밖의 통신은 포트/어댑터를 통해 의존성 제어
경계 설계 시 흔한 실수
- 데이터 중심 경계 설정
- → “DB 테이블 단위”로 서비스를 나누면 경계가 비즈니스 흐름과 어긋남
- 기능 너무 세분화
- → 불필요하게 작은 서비스는 운영 복잡도만 증가
- 모델 언어 혼재
- → 다른 컨텍스트의 용어를 그대로 가져와 모델 혼란 초래
서비스 경계는 전략적 결정
마이크로서비스의 경계는 단순한 개발 편의가 아니라,
조직 구조, 배포 전략, 확장성에 직결되는 전략적 결정입니다.
DDD의 바운디드 컨텍스트 개념을 토대로 경계를 설계하면,
기술뿐 아니라 비즈니스의 언어와 흐름까지 코드에 녹일 수 있습니다.
728x90'기술과 산업 > 아키텍처' 카테고리의 다른 글
소프트웨어 아키텍처 시리즈 15화 – Saga 패턴과 프로세스 오케스트레이션: 분산 트랜잭션을 다루는 전략 (5) 2025.08.13 소프트웨어 아키텍처 시리즈 14화 – 이벤트 기반 시스템의 데이터 일관성 문제와 해결 전략 (3) 2025.07.29 소프트웨어 아키텍처 시리즈 13화 – CQRS 아키텍처의 실전 설계 전략: 분리를 넘어 책임의 정렬로 (3) 2025.07.18 소프트웨어 아키텍처 시리즈 12화 – 이벤트 소싱의 개념과 도입 시 고려사항 (2) 2025.06.27 소프트웨어 아키텍처 시리즈 11화 – 유즈케이스 중심 서비스 설계와 포트 단위 테스트 전략 (0) 2025.06.22