[MSA] 서비스 분리와 도메인 중심 설계(DDD)의 핵심

서비스 분리는 마이크로서비스 아키텍처(MSA)의 시작점이자 가장 중요한 설계 원칙이다.
아무렇게나 쪼갠다고 해서 그것이 MSA가 되지는 않는다.
서비스 분리를 제대로 하기 위해선 도메인 중심 설계(DDD: Domain-Driven Design)에 대한 이해가 필수이다.

✅ 왜 서비스 분리가 중요한가?

MSA에서 서비스는 비즈니스 단위로 나뉘는 독립 실행 가능한 단위이다.
즉, 서비스가 잘 분리되어야 마이크로서비스의 장점인 유연한 배포, 확장성, 독립적인 개발이 가능해진다.
하지만 서비스 경계를 잘못 정하면 오히려 다음과 같은 문제를 낳는다.

• 서비스 간 데이터 공유가 많아지며 트랜잭션 분산 문제 발생
• REST API가 아닌 내부 DB 접근으로 의존도가 심해짐
• 단순 CRUD 서비스만 여러 개로 쪼개어 오히려 개발 속도 저하

따라서 서비스 분리는 “기능적으로 나누는 것”이 아니라 “비즈니스 규칙에 따라 경계를 정의하는 것”에 가깝다.

🎯 도메인 중심 설계(DDD)란 무엇인가?

DDD는 복잡한 소프트웨어를 비즈니스 도메인 중심으로 모델링하여 설계하는 방식이다.
엔티티(Entity), 값 객체(Value Object), 애그리거트(Aggregate), 도메인 이벤트 등 여러 구성요소가 있지만, MSA에서 가장 핵심은 아래 두 가지이다.

1. Bounded Context (경계 구분)
   도메인마다 용어, 규칙, 데이터 구조가 다르기 때문에 구현 경계를 명확히 나눠야 한다.
2. Context Mapping (문맥 연결)
   분리된 서비스들 간의 연계 관계를 계약(Contract), 이벤트(Event), ACL 등으로 정의한다.

이 두 가지 개념을 바탕으로 시스템을 분석하면 자연스럽게 서비스 단위가 도출된다.
즉, MSA는 DDD 없이는 제대로 구현할 수 없다.

반응형

🧠 실전 예시: 이커머스 시스템의 서비스 분리

예를 들어, 온라인 쇼핑몰을 구축한다고 가정해보자.
다음은 흔히 잘못 나눈 서비스 구조의 예이다.

• 회원 서비스
• 상품 서비스
• 주문 서비스
• 배송 서비스
• 결제 서비스

표면적으로는 잘 나눠진 것처럼 보이지만, 실제로는 대부분이 상품 ID, 회원 ID 등으로 서로 강하게 엮여 있음으로 인해 진정한 독립성을 확보하지 못한다.
이런 구조에서는 장애 전파가 심각해지고, 코드 수정 시 여러 서비스 간 동시 배포가 필요하다.

이럴 때는 먼저 DDD 관점에서 도메인을 다음처럼 나눌 수 있다.

• 고객 도메인: 회원, 포인트, 인증
• 상품 도메인: 상품 관리, 재고, 옵션
• 거래 도메인: 장바구니, 주문, 결제, 환불
• 배송 도메인: 출고, 운송장, 상태 추적

이처럼 도메인 별로 책임과 데이터를 나누고, 각각의 도메인을 하나의 Bounded Context로 생각하면 자연스럽게 서비스도 나뉜다.

🛠️ DDD 기반 서비스 분리 시 고려할 사항

• 팀 구조와 일치하도록 분리: DDD는 조직 구조에 맞는 아키텍처를 만드는 데 적합하다. (Conway’s Law)
• 데이터 독립성 보장: 도메인 간 DB 공유는 피하고, API 또는 이벤트로만 연계한다.
• 업무 중심으로 정의: 화면 UI나 테이블 구조가 아닌, 비즈니스 시나리오 기준으로 나누어야 한다.
• 연계 방식 고려: 동기 API, 비동기 메시징, 이벤트 설계 모두 서비스 분리와 연계된다.

서비스 간 데이터 공유가 필요한 경우에는 도메인 이벤트(Event)를 활용하거나, 조회 목적의 ACL(Anti Corruption Layer)를 따로 설계하는 방식이 일반적이다.

반응형

🔄 정적 vs 동적 서비스 분리 전략

분리 방식	설명	예시
정적 분리	처음부터 도메인 분석을 바탕으로 서비스 경계를 미리 나누는 방식이다.	고객 도메인, 주문 도메인 등 명확한 책임에 따라 설계
동적 분리	운영 중 서비스 모니터링을 통해 트래픽, 장애, 성능 병목 지점을 기준으로 나중에 분리하는 방식이다.	검색 기능만 트래픽 폭증으로 별도 서비스로 분리

현업에서는 정적 분석(도메인 중심 설계)을 우선 적용하되, 실제 트래픽과 장애 상황에 맞게 동적으로 보완하는 하이브리드 전략이 많이 쓰인다.

🧩 도메인 기준 분리와 테이블 기준 분리의 차이

많은 개발자들이 RDB 테이블 설계 기준으로 서비스 경계를 나누는 실수를 저지른다.
하지만 이는 잘못된 방법이다.
예를 들어 회원 테이블이 있다고 해서 무조건 회원 서비스로 분리하는 것이 아니다.
해당 기능이 회원 도메인의 책임인지, 고객 도메인에 속하는지를 먼저 판단해야 한다.

DDD에서는 다음 기준을 참고한다.

• 이 기능은 어떤 비즈니스 규칙을 따르는가?
• 실패 시 어느 도메인에 영향을 주는가?
• 유지보수 시 어느 팀에서 책임질 수 있는가?

이런 질문에 답하면서 도메인 경계를 나누면 MSA의 진정한 독립성과 확장성을 얻을 수 있다.

✅ 결론

MSA에서 가장 중요한 시작은 단연 서비스 분리 전략이다.
그 핵심은 도메인 중심 설계를 통해 명확한 Bounded Context를 설정하고, 서비스 간 의존도를 줄이는 것이다.
단순히 기능으로 나누는 것이 아니라, 비즈니스의 본질적인 책임 단위로 나누는 사고 전환이 필요하다.
이것이 진짜 MSA의 출발점이다.

📌 참고한 공식 문서

• Domain-Driven Design 공식 요약 가이드 - dddcommunity.org
• MSA 구조와 서비스 분리 전략 - martinfowler.com
• Spring Cloud와 DDD의 통합 사례 - spring.io