DDD 전략 설계와 전술 설계로 도메인 복잡성 다루기

비즈니스 경계와 코드 모델은 서로 다른 층위에서 결정된다

복잡한 비즈니스 로직을 다룰 때는 시스템 전체에서 무엇을 분리할지와, 분리된 내부를 어떤 모델로 구현할지를 구분해야 한다. 도메인 주도 설계(Domain-Driven Design, DDD)는 이 문제를 전략적 설계와 전술적 설계로 나눈다.

전략적 설계는 비즈니스 맥락과 서비스 경계를 다룬다. 전술적 설계는 그 경계 안에서 도메인 모델을 코드로 구현하는 방법을 다룬다. 두 층위가 연결되면 비즈니스 구조와 소프트웨어 구조 사이의 간극을 줄일 수 있다.

같은 말을 같은 의미로 쓰기 위한 언어와 경계

도메인은 소프트웨어로 해결하려는 비즈니스 영역, 즉 유사한 업무가 모인 범위다. DDD에서는 개발자와 도메인 전문가가 동일한 용어를 사용해야 한다. 이 공통 언어를 보편 언어(Ubiquitous Language)라고 하며, 이해관계자 사이의 개념적 차이를 줄이는 역할을 한다.

컨텍스트는 도메인의 사용자·프로세스·정책이 유효한 환경이다. 보운디드 컨텍스트(Bounded Context)는 비즈니스 목적이 다른 컨텍스트를 묶어 구분한 경계다. 예를 들어 하나의 시스템에서 상품이라는 말이라도 주문 컨텍스트와 배송 컨텍스트에서는 서로 다른 의미를 가질 수 있다. 이 차이를 한 모델에 억지로 합치지 않고 경계로 관리하는 것이 핵심이다.

전략 설계에서 문제 공간을 나누는 방식

전략적 설계는 문제 공간(Problem Space)을 정의하고 해결 공간(Solution Space)을 설계하면서 시스템의 큰 방향을 잡는다.

도메인 분해도는 최상위 도메인을 서브도메인으로 나누는 작업이다. 서브도메인은 비즈니스에서의 중요도와 성격에 따라 구분한다.

• 핵심 도메인(Core Domain): 비즈니스의 독보적인 경쟁력을 만들며 가장 많은 노력이 필요한 영역
• 지원 도메인(Support Domain): 핵심 기능을 돕지만 차별화 요소는 적은 영역
• 일반 도메인(Generic Domain): 범용 소프트웨어 기능으로 대체할 수 있는 공통 영역

컨텍스트 맵(Context Map)은 보운디드 컨텍스트 사이의 관계를 표현한다. 이를 통해 팀 간 Upstream/Downstream 관계와 데이터 흐름을 파악할 수 있다.

이벤트 흐름에서 서비스 경계까지

이벤트 스토밍(Event Storming)은 복잡한 도메인을 빠르게 탐색하는 워크숍 기법이다. 비즈니스에서 의미 있는 상태 변화를 도메인 이벤트로 놓고, 그 흐름을 따라가며 프로세스와 경계를 구체화한다.

도메인 이벤트를 정의한 뒤 이벤트 흐름으로 비즈니스 스토리를 검증한다. 이어서 성격이 비슷한 프로세스를 묶고, 이벤트를 일으키는 커맨드와 외부 시스템 또는 시간 경과에 따른 트리거를 찾는다. 데이터 변경과 비즈니스 규칙의 단위인 애그리게이트를 정한 다음, 최종적으로 보운디드 컨텍스트와 컨텍스트 맵을 확정한다.

⤢✕

전술 설계가 도메인 모델을 구현하는 방법

전술적 설계는 전략적 설계에서 찾은 컨텍스트와 모델을 실제 코드 구조로 옮긴다. 모델 주도 설계(Model Driven Design)를 지향하며, 계층형 아키텍처(Layered Architecture)를 기반으로 구성할 수 있다.

• 표현 계층(Presentation Layer): 사용자 인터페이스와 외부 요청을 처리한다.
• 서비스 계층(Service Layer): 비즈니스 흐름 제어(Flow Control)와 트랜잭션 관리를 맡는다.
• 도메인 계층(Domain Objects): 비즈니스 로직과 도메인 모델이 위치하는 핵심 영역이다.
• 인프라 계층(Data Access/Mapper): 데이터베이스 연동과 외부 기술 라이브러리 처리를 담당한다.

도메인 모델의 무결성을 유지하기 위해서는 다음 패턴을 사용할 수 있다.

• 엔티티(Entity): 식별자를 가지며 상태가 변하는 객체
• 밸류 객체(Value Object): 속성 값 자체에 의미가 있고 식별자가 없는 불변 객체
• 애그리게이트(Aggregate): 연관된 객체를 묶고, 데이터 변경 시 일관성을 지키는 최소 단위
• 팩토리(Factory): 복잡한 애그리게이트 생성 로직을 캡슐화하는 구성 요소
• 리포지토리(Repository): 애그리게이트의 영속성을 맡아 도메인 계층과 데이터 계층을 분리하는 구성 요소

이 단계의 결과물에는 사용자 스토리, 시퀀스 다이어그램, 클래스 다이어그램, 데이터 다이어그램, API 설계서가 포함된다. Saga, CQRS 같은 마이크로서비스 패턴을 적용한 상세 설계도 이 단계에서 완성된다.

컨텍스트 경계가 서비스 구조로 이어지는 흐름

DDD는 큰 구조에서 세부 구현으로 내려오는 방식으로 진행된다. 전략적 설계의 보운디드 컨텍스트는 서비스의 물리적·논리적 경계를 제공하고, 이를 독립적으로 배포·운영할 수 있는 단위로 구현한 것이 마이크로서비스(Micro Service)다. 각 마이크로서비스 내부에서는 계층형 아키텍처로 복잡성을 관리한다.

이 흐름은 비즈니스 요구가 바뀌었을 때 영향을 받는 범위를 분리하는 기반이 된다. 핵심 영역을 식별하는 전략적 판단과, 모델의 응집도를 유지하는 전술적 구현이 함께 작동해야 유지보수 가능한 시스템 구조가 만들어진다.

Sources

• Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software.
• Vernon, V. (2013). Implementing Domain-Driven Design.
• Fowler, M. (2014). Bounded Context. Martinfowler.com.