티스토리 뷰
목차
소프트웨어 구조와 설계 사이,, 그 미묘한 경계에서
✅ 들어가며
최근 MSA 전환에 대해 파고들고 있는데 문득 DDD랑 다른게 무엇인가 MSA는 아키텍처이고 DDD는 디자인 기법 중 하나인가?
DDD는 단순 MSA로 가기 위한 수단 중 하나라고 생각하면 될까? 등 다양한 고민들이 쏟아졌기에 해당 글을 실무에서 어떤 관점으로 받아들여야 하는지 고민하는 개발자들을 위한 정리정도로 받아들이면 좋을 것 같다:)
✅ MSA와 DDD, 정확히 무슨 차이일까?
| 구분 | MSA (Microservice Architecture) | DDD (Domain-Driven Design) |
| 개념 | 시스템을 작은 독립 서비스로 분리하는 아키텍처 스타일 | 복잡한 도메인을 잘 이해하고 모델링 하는 설계 접근 방식 |
| 목적 | 독립 배포, 확장성, 팀 간 분리 등 아키텍처 이점 확보 | 비즈니스 요구사항을 정확하게 반영한 도메인 모델 설계 |
| 적용 범위 | 서비스 간 경계를 어떻게 나누고 통신할지 결정 | 도메인을 어떻게 모델링하고, 책임을 분리할지 결정 |
| 관점 | 시스템 구성, 네트워크 구조, 통신 방식 등 거시적 관점 | 도메인 개념, 로직, 데이터 흐름 등 미시적 관점 |
정리해보면
- MSA는 건축 설계도(Architecture)
- DDD는 공간 활용 계획(Interior Design)
✅ 교집합이 생기는 이유 : 서비스 분리 기준
많은 기업이 MSA로 전환하면서 부딪히는 가장 큰 문제는 바로 "어떻게 서비스를 나눌 것인가"이다.
이때 DDD가 등장한다 왜냐하면 DDD는 도메인을 업무 중심으로 분할하는데 특화되어 있기 때문이다.
예: 물류 시스템
- 주문 도메인, 배송 도메인, 재고 도메인은 각자 독립된 비즈니스 기능을 가진다.
- DDD에서는 이를 Bounded Context로 구분하고
- MSA에서는 이를 독립 서비스로 분리한다.
결국 MSA와 DDD는 동일한 현실 세계의 경계를 다루지만, MSA는 시스템 레벨에서, DDD는 도메인 개념 레벨에서 그 경계를 설정한다는 차이가 있다.
✅ 실무에서의 올바른 관점 정리
💡"MSA는 시스템을 쪼개는 방법이고, DDD는 쪼개는 기준이다."
- MSA만 사용하면 -> 기술적으로만 쪼개게 됨 (예: REST API 기준, DB 기준)
- DDD만 사용하면 -> 좋은 설계는 가능하나 시스템 구현 시 확장성과 독립성이 부족할 수 있음
따라서 MSA는 DDD를 기반으로 쪼개는 게 가장 이상적이다.
실제로 많은 실무에서는 DDD로 모델링 -> MSA로 구현하는 접근을 취한다.
✅ 어떻게 받아들이면 좋을지..
- 두 개념을 머릿속에서 층으로 나눠라
- DDD는 비즈니스 관점의 "의미 있는 경계 설정"
- MSA는 시스템 관점의 "독립 실행 가능한 단위 분할"
- "서비스를 왜 이렇게 나눴지?"라는 질문에 답변해보라
- 단순히 DB 테이블 따라 나눴다면 -> MSA의 기술적 쪼개기
- "이 도메인은 XXX 개념상 독립이다"라고 말할 수 있어야 -> DDD 기반 분할
- Bounded Context -> MSA 서비스 매핑 실습해보기
- 예를 들어 "결제 시스템"에 대해 Bounded Context를 정의해보고, 이를 어떻게 서비스로 분할할지 그려보자
- 실제 서비스 설계 시 DDD 용어를 활용해보자
- Entity, Value Object, Aggregate, Domain Service, Repository 등을 실제 클래스 구조에 녹여보며 DDD를 생활화해보자
✅ 마무리하며
MSA와 DDD는 서로 다르지만,
궁극적으로는 "같은 목표(좋은 시스템 설계)를 지향한다.
- MSA는 '어떻게' 쪼갤지
- DDD는 '왜' 쪼개야 하는지를 설명해주는 역할이다.
이 둘을 제대로 구분하고 적절히 조합할 수 있을 때, 비로소 "기술로부터 비즈니스를 해방시킬 수 있는 시스템"을 만들 수 있다.
🔖참고 키워드
- Bounded Context
- Aggregate Root
- Context Mapping
- Decentralized Data Management
- 팀 간 책임 분리