안녕하세요, 카카오클라우드입니다. 오늘은 도메인 주도 설계(Domain Driven Design, 이하 DDD)에 대해 알아보려고 합니다.
소프트웨어 개발은 왜 어려울까요? 소프트웨어 개발 과정에서 종종 이런 상황이 발생합니다. 개발팀이 몇 달 동안 열심히 만든 시스템이 완성되었지만, 기획자와 실제 사용자들은 "이게 제가 원하던 것이 아닌데요"라고 말합니다. 또는 비즈니스 부서가 요청한 내용이 개발팀에게 전달되는 과정에서 의미가 왜곡되어 전혀 다른 결과물이 나오기도 합니다.
이런 문제의 핵심에는 소통의 단절이 있습니다. 비즈니스 부서는 그들만의 전문 용어로 이야기하고, 개발자들은 기술적 용어로 생각합니다. 마치 서로 다른 언어를 사용하는 사람들이 통역 없이 대화하는 것과 비슷합니다. 오늘 다룰 주제인 DDD는 바로 이 간극을 해소하기 위한 접근법입니다.
DDD란 무엇인가요?
DDD는 2003년 에릭 에반스가 소개한 소프트웨어 개발 방법론으로, 핵심 아이디어는 아주 단순합니다: 비즈니스 영역(도메인)의 언어와 개념을 소프트웨어 설계의 중심에 두자는 것입니다.
여기서 '도메인'이란 소프트웨어가 해결하고자 하는 영역을 말합니다. 예를 들어, 은행 애플리케이션의 도메인은 금융 서비스이고, 병원 관리 시스템의 도메인은 의료 서비스입니다.
쉬운 예시로 개념을 이해하기 위해 도서관 관리 시스템을 만든다고 가정해보겠습니다.
전통적인 방식
개발자들은 보통 데이터베이스 테이블부터 설계합니다. "user" 테이블, "book" 테이블, "loan" 테이블 등을 만들고, 각 테이블의 필드를 정의합니다. 그리고 이 데이터를 처리하는 코드를 작성합니다.
이 접근법의 문제는 도서관 사서가 실제로 어떻게 일하는지, 어떤 규칙과 과정을 따르는지에 대한 깊은 이해 없이 시스템이 설계된다는 점입니다.
DDD 방식
DDD에서는 먼저 도서관 직원들과 대화하며 그들의 언어와 개념을 배웁니다.
- 사서들은 '대출자'(사용자가 아님)에게 '자료'(책만이 아니라 DVD, 잡지 등)를 '대출'해줍니다.
- '대출'에는 '반납 기한'이 있고, 기한을 넘기면 '연체료'가 발생합니다.
- 인기 있는 자료는 '예약'이 가능하며, '대기 목록'이 형성됩니다.
이런 용어와 개념을 그대로 소프트웨어 설계에 반영합니다. 개발자와 사서가 같은 언어로 소통하게 되므로, 오해의 가능성이 줄어듭니다.
DDD의 핵심 개념들
1. 유비쿼터스 언어(공통 언어)
DDD의 가장 중요한 개념은 유비쿼터스 언어(공통 언어)입니다. 이는 개발팀과 비즈니스 팀이 함께 사용하는 공통 용어집으로 모든 대화, 문서, 코드에서 일관되게 사용됩니다.
2. 바운디드 컨텍스트
큰 조직에서는 같은 단어도 부서마다 다른 의미를 가질 수 있습니다. DDD에서는 이런 개념적 경계를 바운디드 컨텍스트라고 부릅니다. 예를 들어 병원에서 환자라는 단어는 접수처, 진료실, 약국에서 각각 다른 의미를 가집니다. 접수처는 예약 및 개인정보 관리 대상이며, 진료실에서는 진단과 치료가 필요한 사람을, 약국은 처방전을 가진 고객을 의미합니다. 이처럼 같은 단어도 상황(컨텍스트)에 따라 의미가 달라질 수 있으므로, 각 상황에 맞는 모델을 따로 설계합니다.
3. 엔티티와 값 객체
DDD에서는 도메인 모델의 구성 요소를 두 가지로 구분합니다. 먼저 엔티티는 고유한 정체성이 있어 시간이 지나도 동일하게 식별되는 것입니다. 예를 들어 주민등록번호는 같은 이름의 사람이 여러 명 있어도 특정 개인을 식별할 수 있습니다. 반면, 값 객체는 속성의 값만으로 식별되며, 값이 모두 같으면 동일한 것으로 간주됩니다. 예를 들어 같은 금액의 지폐는 모두 동일하게 취급되는 것과 같습니다.
4. 애그리게이트와 애그리게이트 루트
애그리게이트는 함께 취급되어야 하는 객체들의 집합입니다. 마치 한 그룹처럼 서로 연결되어 있습니다. 각 집합에는 애그리게이트 루트라는 대표가 있어, 외부에서는 이 대표를 통해서만 집합의 구성원에게 말을 걸 수 있습니다. 예를 들어 주문서(애그리게이트 루트)와 그에 포함된 여러 주문 항목들(구성원)이 있다면 외부에서는 주문서를 통해서만 하위 항목을 추가하거나 변경할 수 있습니다.
5. 도메인 서비스
때로는 어떤 개념이 특정 객체에 자연스럽게 속하지 않는 경우가 있습니다. 이런 경우 도메인 서비스로 분리합니다. 예를 들어 은행 계좌 간 송금은 출금 계좌나 입금 계좌 어느 한쪽에만 속하지 않기 때문에 이런 경우 ‘송금 서비스’라는 별도의 서비스를 만들어 처리할 수 있습니다.
DDD가 주는 실질적인 가치
1. 소통 개선
가장 큰 장점은 비즈니스 팀과 개발 팀 사이의 소통이 원활해진다는 것입니다. 모두가 같은 언어로 이야기하기 때문에, "우리가 원하는 건 이게 아닌데..."라는 상황이 크게 줄어듭니다.
2. 변화에 유연하게 대응
비즈니스 규칙과 프로세스가 코드에 명확하게 반영되어 있기 때문에, 비즈니스 요구사항이 변할 때 수정해야 할 부분을 쉽게 찾을 수 있습니다.
3. 복잡성 관리
큰 시스템을 바운디드 컨텍스트로 나누어 관리하면, 각 부분을 독립적으로 이해하고 발전시킬 수 있습니다.
DDD의 한계와 적용 시 고려사항
1. 모든 프로젝트에 적합하지 않음
DDD는 비즈니스 로직이 복잡한 시스템에 가장 효과적입니다. 단순한 데이터 입출력 위주의 시스템에는 과도한 접근법일 수 있습니다.
2. 초기 시간 투자 필요
도메인을 깊이 이해하고 모델을 구축하는 데 시간이 필요합니다. 빠른 출시가 중요한 프로젝트에서는 이런 초기 투자가 부담스러울 수 있습니다.
지금까지 DDD에 대해 살펴보았습니다. 도메인 주도 설계는 단순한 기술적 방법론이 아니라, 소프트웨어 개발에 대한 새로운 사고방식입니다. 기술보다 비즈니스를 중심에 두고, 모든 관계자가 같은 언어로 소통하게 함으로써, 비즈니스 가치를 더 잘 구현하는 소프트웨어를 만들 수 있게 합니다.
DDD는 비즈니스와 개발 사이의 다리를 놓기 위한 대화의 시작점입니다. 이 접근법을 통해 개발자는 단순한 코드 작성자가 아닌, 비즈니스 문제를 함께 해결하는 파트너로 성장할 수 있습니다.
댓글