DDD를 프로젝트에 적용하려면?
배경
프로젝트에서 DDD 방법론을 사용하자는 의견이 나왔다. 저번 프로젝트에서도 사용을 했고 이벤트 스토밍으로 유비쿼터스 언어를 정할 수 있어서 좋다고 생각했는데 이번에는 좀 더 본격적으로 사용하면 좋을거라고 생각으로 조사한 내용을 정리하려고 한다.
DDD란?
DDD란 domain drvien design으로 복잡한 비즈니스 문제 영역(도메인)을 소프트웨어 설계의 중심에 두는 개발 방법론으로, 소프트웨어 구현 방법론 중 1개이며 애자일 + DDD 또는 워터풀 + DDD로 사용 가능하다.
DDD 특징
- 도메인 로직에 집중: 데이터베이스 중심의 설계가 아닌, 순수한 비즈니스 규칙과 로직에 초점 맞춤
- 유비쿼터스 언어: 도메인 전문가와 개발자가 분석, 설계, 그리고 코드에 이르기까지 동일한 표현과 단어로 구성된 통일된 언어 체계 구축
- 모델과 코드의 일치: 소프트웨어의 엔티티와 도메인 개념을 가능한 한 가깝게 일치시켜, 도메인에서 발생하는 변화를 코드에 쉽게 반영
📝 DDD 적용 1차: 도메인 분석과 전략적 설계
1차 과정은 도메인을 깊이 이해하고, 그 이해를 소프트웨어 모델로 풀어내는 반복적인 설계·구현 과정을 진행한다. 아래 단계들은 순서가 아닌 여러 번 왕복하며 모델을 다듬어 가는 순환적인 활동(Continuous Refinement)이다. (1차 과정은 팀원 모두가 같이 하여 도메인에 대해 자세히 아는 것이 중ㅇ요하다)
1. 이벤트 스토밍 워크숍으로 도메인 탐색
도메인 전문가와 개발자가 한자리에 모여, 비즈니스 흐름에서 발생하는 중요한 사건들을 "도메인 이벤트" 형태로 시간 순서대로 나열한다. 이를 통해 복잡한 비즈니스 프로세스를 빠르게 시각화하고, 팀이 공유하는 유비쿼터스 언어의 기초를 만듭니다.
이벤트 스토밍 진행 방법
2. 전략적 설계: 경계 컨텍스트와 컨텍스트 매핑
이벤트 스토밍에서 드러난 이벤트 흐름과 용어의 의미 변화 지점을 기준으로, 도메인을 여러 개의 경계 컨텍스트(Bounded Context)로 나눕니다. 각 컨텍스트 간의 통합 방식과 의존 관계는 컨텍스트 매핑(Context Mapping)으로 표현하한다. 전체 시스템의 협력 구조를 정의하는 단계
3. 전술적 설계 1: 애그리거트와 도메인 모델링
각 경계 컨텍스트 내부에서 비즈니스 규칙과 트랜잭션 일관성을 함께 묶어야 하는 범위를 중심으로 애그리거트(Aggregate)를 선정한다. 애그리거트 루트, 엔티티, 값 객체와 같은 전술적 패턴을 사용해 모델을 구체화하고, 애그리거트가 경계 컨텍스트 내의 일관성 규칙을 잘 표현하도록 정제한다.
4. 전술적 설계 2: 유스케이스 기반 행위 정의
유스케이스와 사용자 스토리를 분석해 사용자가 시스템에서 수행하는 작업(Command)과 그에 따른 도메인 동작을 정리합니다. 이를 바탕으로 애그리거트와 도메인 서비스의 메서드, 응용 서비스의 흐름을 정의하며, 필요 시 앞 단계(애그리거트 설계나 경계 컨텍스트 설계)로 돌아가 모델을 반복적으로 개선한다.
🛠️ DDD 적용 2차: 구현 설계와 개발
1차에서 도메인 모델과 경계 컨텍스트를 정리했다면, 2차에서는 이를 실제 시스템 구조와 코드로 옮겨가는 작업을 진행한다. 이 단계 역시 구현을 하면서 다시 모델을 수정하는 순환 구조를 가진다. (2차부터는 개발자들이 모여서 의논하는 것이 핵심이다.)
1. 도메인 모델을 담을 아키텍처 선택
도메인 계층을 기술 세부사항(웹, DB 등)으로부터 분리할 수 있는 [레이어드,헥사고날, 클린 아키텍처 등등] 패턴을 선택한다. (필요 시 CQRS나 이벤트 소싱을 고려 가능하다)
- 구조 명확화: "도메인 레이어에 애그리거트·엔티티·값 객체·도메인 서비스가 위치하고, 응용 레이어/어댑터 레이어가 이를 이용한다"는 구조를 명확
2. 테스트 전략 및 개발 방식 정의 (필수X)
도메인 모델을 신뢰할 수 있게 유지하기 위해 어떤 테스트 전략을 쓸지 결정해야한다. 유비쿼터스 언어를 그대로 사용하는 테스트 코드 작성을 목표로 합니다.
- 테스트 대상: 도메인 모델을 대상으로 하는 단위 테스트, 유스케이스 단위의 통합 테스트, 경계 컨텍스트 간 협력을 검증하는 E2E 테스트 등을 정의한다.
- 개발 방식: 팀 상황에 따라 TDD, ATDD, BDD 등 적용 여부와 범위를 정한다.
3. 구현 및 반복적 리팩터링
1차에서 정의한 경계 컨텍스트·애그리거트·유스케이스를 기준으로 응용 서비스, 도메인 모델, 인프라스트럭처 등등을 구현합니다.
- 구현 과정에서 발견되는 모델의 부족함이나 불편함은 다시 1차 설계 단계로 피드백하여, 모델과 코드가 함께 발전(Continuous Refinement)하도록 반복적으로 리팩터링한다.
결론
DDD와 함께 사용할 수 있는 방법론이 있다고 생각하지 못 했다. DDD가 방법론이라서 다른 것을 사용 안 하다고 여겼는데 조사를 통해서 다른 것임을 확인하고 어떻게 하면 DDD에서 추구하는 바를 프로젝트 전반에 녹여 낼 수 있을까 고민하게 되어서 조사하는 시간이 즐겁고 재미있었다.
참고 자료
