도메인 주도 설계

DDD란 무엇인가

도메인 주도 설계(Domain-Driven Design, DDD)는 풀어야 할 업무 영역, 즉 도메인을 소프트웨어 설계의 중심에 두는 접근이다. 기술 구조나 데이터베이스 테이블에서 출발하는 대신, 업무가 실제로 어떻게 돌아가는지를 모델로 옮기고 그 모델이 코드와 일치하도록 만든다.

복잡한 업무일수록 화면과 데이터만으로는 본질을 담기 어렵기 때문에, 업무 규칙과 흐름 자체를 일급 시민으로 다루는 것이 DDD의 출발점이다. 결과적으로 코드가 곧 업무를 설명하는 문서가 되도록 설계 방향을 잡는다.

유비쿼터스 언어

DDD의 토대는 현업 전문가와 개발자가 공유하는 단일한 용어 체계, 곧 유비쿼터스 언어다. 같은 개념을 회의에서는 다른 말로, 코드에서는 또 다른 변수명으로 부르면 번역 과정에서 의미가 새어 나간다.

업무에서 쓰는 단어를 클래스·메서드·테이블 이름에 그대로 반영해 대화와 코드 사이의 간극을 없앤다. 이렇게 정렬된 언어는 요구사항 누락과 해석 충돌을 줄이고, 신규 인력의 합류 비용도 낮춘다.

바운디드 컨텍스트

규모가 큰 도메인을 하나의 거대한 모델로 묶으면 용어가 충돌하고 결합도가 폭발한다. DDD는 의미가 일관되게 통하는 경계를 그어 도메인을 바운디드 컨텍스트 단위로 나눈다.

예컨대 같은 회원이라는 단어도 결제 영역과 배송 영역에서 다루는 속성과 규칙이 다르므로, 경계를 분리해 각자의 모델을 유지한다. 이 경계 구분은 마이크로서비스 아키텍처(MSA)에서 서비스를 나누는 자연스러운 기준선이 되며, 컨텍스트 사이의 관계를 명시한 지도를 통해 통합 지점을 통제한다.

전술적 설계 요소

컨텍스트 내부의 모델은 몇 가지 구성 요소로 정교화된다. 고유한 식별자로 추적되는 엔티티, 식별자 없이 속성으로만 동등성이 판단되는 값 객체, 그리고 일관성을 함께 지켜야 하는 객체 묶음인 애그리거트가 핵심이다.

애그리거트는 하나의 루트를 통해서만 외부와 상호작용하게 하여 불변식이 깨지지 않도록 보호한다. 영속성 접근은 리포지토리로 추상화하고, 어느 한 객체에 자연스럽게 속하지 않는 연산은 도메인 서비스로 분리한다.

이러한 객체 지향 모델링 기법이 업무 규칙을 코드 구조 안에 안정적으로 안착시킨다.

계층 분리와 책임

DDD는 도메인 모델을 외부 기술로부터 격리하기 위해 책임을 계층으로 나눈다. 사용자 인터페이스, 응용, 도메인, 인프라스트럭처로 역할을 구분하는 계층형 아키텍처가 그 기본 형태이며, 도메인 계층은 프레임워크나 저장소 같은 세부 기술에 의존하지 않도록 둔다.

이렇게 핵심 규칙을 안쪽에 두고 기술적 관심사를 바깥으로 밀어내면, 데이터베이스나 메시징 수단이 바뀌어도 업무 로직이 흔들리지 않는다. 의존성의 방향을 안쪽으로 향하게 통제하는 것이 유지보수성과 테스트 용이성을 좌우한다.

적용의 전제와 비용

DDD는 모든 시스템에 어울리는 만능 해법이 아니다. 단순한 조회·등록 위주의 시스템에 전술적 패턴을 전면 도입하면 오히려 구조가 과해져 생산성이 떨어진다.

진가는 업무 규칙이 복잡하고 변화가 잦으며, 현업과 긴밀한 협업이 필요한 핵심 도메인에서 드러난다. 따라서 전체를 똑같이 설계하기보다, 경쟁력의 원천이 되는 핵심 영역에 모델링 역량을 집중하고 주변 영역은 가볍게 다루는 선택과 집중이 현실적이다.

도입 전 도메인의 복잡도와 팀의 모델링 숙련도를 함께 가늠해야 한다.