토비님의 토비의 클린 스프링 – 도메인 모델 패턴과 헥사고날 아키텍처 Part 1 강의에서 DDD란 용어를 듣기 전에도 DDD란 말은 많이 들었다. 채용 공고에서도 DDD란 용어가 많이 나왔다. DDD에 대해서 하나씩 그리고 천천히 공부를 하는데도 항상 헷갈리고 어렵다. 일부분 혹은 단편적인 것만 보고 이해하기에는 어려운 DDD이지만 오늘도 공부를 해본다
DDD는 EXID의 덜덜덜(DDD)과 나 혼자 산다 팜유특집에서 나오던 노래 가수 김혜림님의 DDD로 익숙하지만, 소프트웨어와 관련된 DDD에 대해서 자세히 알아보기로 했다
도메인 주고 설계를 알기 전에 도메인(Domain)과 도메인 모델(Domain Model)에 대해서 먼저 알아보자
도메인(Domain)과 도메인 모델(Domain Model)
도메인 주도 설계(DDD)를 이해하기 위해서는 먼저 ‘도메인’과 ‘도메인 모델’이라는 용어의 의미를 정확히 파악하는 것이 중요하다. 이 용어들은 단순히 기술적인 개념을 넘어, 소프트웨어 개발의 근본적인 목적과 방향성을 제공한다
일반적인 ‘도메인’의 의미
- ‘도메인’이라는 단어는 원래 ‘영토’나 ‘소유지’를 의미했으니, 점차 그 의미가 확장되어 ‘지식이나 활동의 특정 영역 또는 분야’를 가리키게 되었다. 어떤 명확한 경계를 가진 특정 활동이나 지식의 집합을 도메인이라고 부를 수 있다
- 예를 들어, “나는 이커머스 도메인에서 일해봤다”라고 말한다면, 이는 특정 회사의 업무가 이커머스 분야에 속하며, 그 분야의 지식과 경험을 가지고 있다는 의미이다
네이버에서 도메인을 어학사전으로 검색한 결과
- (지식·활동의) 영역[분야], (책임의) 범위 (→public domain)
- (특히 옛날 개인·정부 등의) 소유지[영토]
- 인터넷상에서 개인이 소유하고 있는 인터넷 주소
- The care of older people is being placed firmly within the domain of the family.
- 노인 부양이 가족 범위 내에서 해야 될 일로 단단히 한정되고 있다.
- Dokdo is in the Korean domain.
- 독도는 한국 영토 내에 있다.
- Users cannot remember long domain names.
- 사용자는 긴 도메인 이름을 기억하지 못한다.
소프트웨어 개발에서의 ‘도메인’
- 소프트웨어는 항상 특정 사용자의 활동, 업무, 관심사와 관련이 있다. 즉, 소프트웨어가 적용되는 사용자의 활용 영역 또는 문제 해결 영역이 바로 소프트웨어 개발에서의 ‘도메인’이다. 모든 소프트웨어는 특정 도메인을 위해 존재하며, 개발자는 이 도메인의 특성과 작동 방식을 깊이 이해하고 소프트웨어에 반영해야 한다
- 소프트웨어 개발 과정에서 “이 소프트웨어는 어떤 도메인을 위함 것인가?”, “이 도메인은 어떤 특성을 가지고 있는가?”와 같은 질문을 통해 도메인을 이해하는 것이 프로젝트 성공의 핵심이다. 이러한 관점에서 도메인을 ‘문제 영역(Problme Domain)’이라고 부르기도 하는데, 이는 소프트웨어가 해결하고자 하는 실제 세계의 문제 또는 요구사항이 존재하는 영역을 의미한다
도메인 모델
- 도메일 모델이란 도메인의 핵심을 소프트웨어 형태로 ‘모델링’하는 것이다. 도메인 모델을 소프트웨어 도메인의 핵심 개념, 요소, 그리고 그들 간의 관계 및 규칙을 추상화하고 단순화한 형태이다.
- 현실 세계의 도메인은 매우 복잡하고 변화무쌍하기 때문에 그 모든 것을 코드에 그대로 옮겨 담는 것은 불가능하며 비효율적이다. 따라서 개발자는 도메인에서 가장 중요하고 핵심적인 요소들을 추출하여 추상화된 모델을 만들어야 한다
도메인 모델의 측징
- 추상화된 지도: 도메인 모델은 소프트웨어가 해결하고자 하는 문제 영역에 대한 ‘핵심 지도’와 같다. 현실의 복잡성을 걷어내고 소프트웨어 관점에서 알아야 할 가장 중요한 개념들만 뽑아낸 것이다
- 핵심 요소와 관계: 도메인에 존재하는 중요한 개념들(주로 명사로 표현되는 엔티티, 값, 객체 등)을 식별하고 이들 사이의 관계(예: 고객은 책을 주문한다)를 명확히 정의한다
- 비즈니스 규칙 포함: 도메인에 내재된 중요한 비즈니스 규칙(예: “주문 총액은 장바구니에 담긴 상품의 가격과 수량을 합산하여 계산한다”)과 행위들을 포함한다
- 멘탈 모델: 도메인 모델은 단순히 다이어그램이나 문서와 같은 물리적인 형태뿐만 아니라, 개발팀 구성권들의 머릿속에 공유된 ‘멘탈 모델(Mental Model)’이기도 한다. 이러한 공유된 이해를 바탕으로 소프트웨어를 개발하고 유지보수해 나간다
온라인 서점 도메인 모델 (예시)
- 개념: 책(Book), 고객(Customer), 주문(Order), 장바구니(Cart) 등
- 관계: 고객은 책을 장바구니에 담고 주문한다
- 규칙 / 행위: 장바구니에 담긴 상품의 가격과 수량을 합산하여 계산한다
이러한 도메인 모델은 소프트웨어 개발의 지도가 되어 개발팀이 공통된 이해를 바탕으로 목표를 향해 나아가도록 돕는다
도메인 주도 설계 (DDD)
- DDD는 Domain-Driven Design의 약자로, 간혹 ‘Domain-Driven Development(도메인 주도 개발)’로 오해될 수 있으나, 이는 특정 개발 방법론이라기 보다는 복잡한 비즈니스 도메인의 문제를 해결하기 위한 소프트웨어 설계 접근 방식이다. 소프트웨어가 시간이 지남에 따라 복잡성이 증가하고 끊임없이 변화하는 현실 속에서 DDD는 이러한 복잡성을 효과적으로 관리하기 위한 해법을 제시한다
DDD의 핵심: 도메인 모델 중심의 사고
- DDD의 본질은 ‘도메인 모델’을 소프트웨어 설계의 중심에 두는 것이다. 여기서 도메인 모델은 단순한 데이터 구조가 아니라 비즈니스 로직과 행동을 풍부하게 담고 활기찬 존재(Rich Domain Model)가 되어야 한다. 이러한 접근 방식을 통해 소프트웨어 비즈니스 요구사항을 정확하게 반영하고 유연하게 대응할 수 있는 결고한 구조를 갖추게 된다
- 많은 경우 DDD를 엔티티, 값 객체, aggregate(애그리거트? 애그리게이트?), 리포지토리와 같은 전술적 패턴이나 바운디드 컨텍스트, 컨텍스트 맵과 같은 전략적 패턴의 집합으로 오해하기도 한다. 물론 이 패턴들은 DDD를 구현하는 데 필수적인 도구이지만, DDD의 진정한 핵심은 이러한 패턴들을 활용하여 도메인 모델을 잘 만들고 지속적으로 발전시키는 철학이자 활동에 있다
DDD의 성공 조건: 현업 전문가와의 협업
- DDD는 개발자만의 활동이 아니다. 복잡한 도메인의 본질을 이해하고 모델링하는 것은 오직 도메인을 가장 잘 아는 현업 전문가(Domain Expert)의 통찰력이 있어야 가능하다. 즉, 개발팀뿐만 아니라 현업 전문가를 포함한 다양한 이해관계자들이 모두 참여하여 함께 도메인 모델을 만들고 발전시키는 것이 DDD에서 가장 중요한 활동이다
- 초기 요구사항 분석 단계에서의 일회성 미팅으로는 DDD라도 할 수 없다. 개발 과장 전반에 걸쳐 현업 전문가와 개발자가 지속적으로 소통하고 도메인 모델을 함께 발전시켜 나가는 것이 핵심이다
DDD를 이끄는 두 가지 핵심 축
모델 주도 설계 (Model-Driven Design)
- 문제점: 전통적인 개발 방식에는 분석-설계-구현 단계로 경직되게 분리되어, 각 단계에서 도메인에 대한 이해가 왜곡되거나 소실되는 문제가 번번하다. 분석 단계의 도메인 모델이 설계와 구현 단계로 넘어오면서 점점 본래의 의미를 잃고 결국 현업 전문가의 실제 요구사항과 동떨어진 코드가 만들어지곤 했다
- DDD의 해법: 도메인 모델은 한 번 만들어진 문서로 끝나는 것이 아니라, 소프트웨어 개발 전 과정(설계와 코드 구현)에 걸쳐 핵심적인 역할은 해야 한다는 원칙이다. 즉, 도메인 모델이 설계와 코드에 지속적으로 반영되어야 하며 반대로 코드 구현 과정에서 더 나은 도메일 모델에 대한 통찰을 얻는다면, 그 내용이 도메일 모델에도 다시 반영되어야 한다. 이는 모델과 코드가 끊임없이 상호작용하며 진화하는 과정이다
보편 언어 (Ubiquitous Language)
- 문제점: 실무 현장에서는 같은 개념에 대해 다른 용어를 사용하거나 모호한 표현을 사용하는 경우가 많아, 이해관계자들 사이에 오해를 불러일으키로 소통의 효율성을 떨어뜨린다
- DDD의 해법: 도메인 전문가를 포함한 모든 이해관계자가 도메일 모델에 기반한 단일한 어휘 체계를 만들고 이를 문서, 회의, 대화, 그리고 코드에 이르기까지 일관되게 사용해야 한다. 이는 단순히 용어집을 만드는 것을 넘어 모든 팀원이 의식적인 노력을 통해 같은 개념에 같은 단어를 사용하고 같이 이해를 공유하는 문화를 구축하는 것을 의미힌다. 보편 언어는 도메인 안에서 어디에서나 통용되어야 한다
DDD의 철학
DDD는 개발자가 도메인에 깊이 집중하고, 코드와 모델을 긴밀하게 일치시키며, 모든 이해관계자가 명확하고 일관된 언어를 사용하도록 하는 데 그 철학적 기반을 둔다. 이러한 접근 방식은 단지 코드를 잘 짜는 기술이 아니라, 복잡한 소프트웨어를 체계적으로 설계하고 장기적으로 유지보수하기 위한 사고방식의 전환을 가져온다