DDD와 UML: 도메인 설계와 모델 표현의 역할 구분

설계 판단과 표현 수단은 같은 일이 아니다

복잡한 비즈니스 소프트웨어를 다룰 때 DDD와 UML은 함께 등장하지만, 맡는 일은 다르다. DDD는 도메인 지식을 모델로 옮기고 경계를 결정하는 설계 방법론이다. UML은 그 모델의 구조와 동작을 시각화하고 문서화하는 표준 표기 언어다.

DDD에서는 유비쿼터스 언어를 바탕으로 서브도메인과 바운디드 컨텍스트를 구분한다. 이후 애그리게이트, 엔티티와 값 객체, 도메인 이벤트, 리포지토리 같은 전술적 설계 요소를 다룬다. UML은 클래스, 시퀀스, 상태, 활동, 컴포넌트, 배포 다이어그램처럼 서로 다른 관점의 뷰를 제공한다.

따라서 DDD는 무엇을 모델링하며 왜 그 경계로 나눌지 판단하는 데 쓰이고, UML은 그 판단 결과를 일관된 형태로 전달하는 데 쓰인다. 둘은 경쟁하는 선택지가 아니라 함께 사용할 수 있는 보완 관계다.

⤢✕

도메인 경계는 DDD로, 공유할 뷰는 UML로 다룬다

DDD는 문제 공간을 탐색하고 설계 의사결정의 기준을 세운다. 팀의 책임 경계를 정하고, 컨텍스트 간 협력 방식과 계약을 설계하는 일이 여기에 속한다. 산출물로는 바운디드 컨텍스트, 컨텍스트 맵, 애그리게이트 규칙, 도메인 정책, 이벤트 카탈로그가 남는다.

UML은 그렇게 정해진 구조와 행위를 정확히 드러낸다. 클래스, 시퀀스, 상태, 컴포넌트, 배포 다이어그램과 명세 문서는 모델을 전달하는 수단이다. 요구·설계·구현 단계에서 필요한 관점만 골라 작성할 수 있다.

DDD는 초기 도메인 발견부터 아키텍처 분해와 지속적 리팩터링까지 이어진다. 반면 UML은 모든 다이어그램을 완성하는 데 목적이 있지 않다. 필요한 시점에 필요한 뷰를 남기는 편이 모델과 문서의 간극을 줄인다.

유비쿼터스 언어는 분석가, 개발자, 도메인 전문가가 같은 의미로 대화하게 만드는 기반이다. UML의 표준 표기법은 그 의미를 구조화해 전달하고, 신규 인력의 온보딩에도 활용할 수 있다.

품질 특성에서 서로 다른 방식으로 기여한다

지표	DDD의 기여	UML의 기여
성능	애그리게이트 경계로 동시성 충돌·과도한 조인 감소, CQRS/도메인 이벤트로 읽기 최적화 유도	시퀀스 다이어그램으로 왕복 호출·병목 식별, 클래스 관계 복잡도 시각화
확장성	바운디드 컨텍스트로 서비스 분리·독립 배포, 이벤트 주도 통합 촉진	배포/컴포넌트 다이어그램으로 스케일 아웃 토폴로지 설계
일관성	애그리게이트 불변식·최종 일관성 규칙 명시, 컨텍스트 간 계약 관리	상태/활동 다이어그램으로 상태 전이·업무 규칙 문서화
안정성	장애 격리 경계 확립, 핵심/지원/일반 서브도메인 분리로 변경 영향 축소	장애 시나리오를 시퀀스/컴포넌트 뷰로 시뮬레이션
운영 편의	팀 경계와 책임 명확화, 변경 관리·우선순위 설정 용이	표준화된 문서로 온보딩·감사·규정 준수 대응 용이

설계 상황에 따라 접근을 연결하는 방법

신규 서비스에서는 이벤트 스토밍으로 도메인 사건을 발견하고 유비쿼터스 언어를 정립한 뒤, 서브도메인과 바운디드 컨텍스트를 도출할 수 있다. 이 과정에서 컨텍스트 맵의 파트너십, 순응, 공개 호스트 서비스 관계와 초기 애그리게이트 규칙을 정리한다. 핵심 컨텍스트의 협력 흐름은 클래스와 시퀀스 다이어그램으로 명세한다.

레거시 모놀리식을 분리할 때는 트랜잭션과 변경 이력을 기준으로 경계를 추출하고 컨텍스트 분리 계획을 세운다. 반부패 계층(ACL) 전략과 점진적 분해 로드맵을 마련한 뒤, 컴포넌트·배포 다이어그램으로 분리 단계와 인터페이스 계약을 보이게 할 수 있다.

마이크로서비스 통합에서는 컨텍스트 간 계약을 정의한 뒤 동기·비동기 통신 정책과 사건 흐름을 설계한다. 도메인 이벤트 스키마와 팀 토폴로지 매핑이 DDD 관점의 산출물이 되며, 사가와 보상 트랜잭션 시나리오는 시퀀스·상태 다이어그램으로 표현할 수 있다.

규제 대응과 변경 관리에서는 규정 요구사항을 도메인 정책에 맵핑하고 불변식 및 감사 추적을 정의한다. 정책 집합과 변경 영향 분석 매트릭스를 유지하면서, 승인과 예외 처리 절차는 상태·활동 다이어그램으로 투명하게 문서화한다.

모델의 일관성을 운영까지 가져가기

요구 해석 오류로 인한 재작업률 2040% 감소 가정과 변경 리드타임 1530% 단축을 기대할 수 있다. 장애 격리에 따라 MTTR 1025% 개선, 신규 인력 온보딩 기간 2035% 단축도 기대 효과에 포함된다.

도메인 중심의 의사결정 문화가 자리 잡으면 팀 사이의 책임과 계약을 명확히 다루기 쉬워진다. DDD로 경계와 규칙을 우선 결정하고, 그 결과를 설명하는 데 필요한 핵심 UML 뷰만 유지하면 문서와 구현 사이의 의미 일치를 강화하면서 커뮤니케이션 비용을 줄일 수 있다.