도메인 주도 설계 DDD 기초편집자 확인

도메인 주도 설계에서 도메인은 소프트웨어가 해결하려는 특정 비즈니스 분야나 문제 영역을 가리킨다. 예를 들어, 은행 시스템의 도메인은 '금융'이며, 전자상거래 시스템의 도메인은 '판매'와 '고객 관리'가 될 수 있다. 도메인은 단순히 기술적인 기능의 집합이 아니라, 해당 비즈니스의 규칙, 프로세스, 전문 지식이 담겨 있는 핵심 영역이다.

복잡한 하나의 도메인은 보다 작고 관리 가능한 단위인 하위 도메인으로 분해될 수 있다. 하위 도메인은 도메인 내에서 특정한 책임이나 기능을 담당하는 부분 영역이다. 일반적으로 하위 도메인은 다음과 같은 세 가지 유형으로 분류된다.

도메인을 하위 도메인으로 식별하고 분류하는 것은 설계의 첫걸음이다. 이 과정을 통해 팀은 어디에 집중해야 하는지(핵심 하위 도메인)와 어디는 표준 솔루션을 적용할 수 있는지(일반 하위 도메인)를 명확히 이해하게 된다. 각 하위 도메인은 이후 서로 다른 제한된 컨텍스트로 발전하여 독립적으로 모델링되고 구현되는 경우가 많다.

유비쿼터스 언어는 특정 도메인 내에서 모든 이해관계자들이 공통으로 사용하는 정제되고 통일된 언어 체계를 의미한다. 이 언어는 도메인 전문가와 개발 팀 사이의 의사소통 장벽을 해소하기 위해 만들어지며, 도메인에 대한 논의, 설계 문서, 코드, 심지어 테스트 케이스에 이르기까지 모든 곳에서 일관되게 사용된다. 유비쿼터스 언어의 핵심 목표는 도메인 지식을 명확하고 모호함 없이 표현하여 소프트웨어 모델이 실제 비즈니스 개념을 정확하게 반영하도록 하는 것이다.

유비쿼터스 언어는 자연스럽게 형성되지 않으며, 지속적인 협업과 리팩토링을 통해 발전한다. 도메인 전문가와 개발자는 도메인에 대한 대화를 통해 핵심 개념, 규칙, 프로세스를 정의하고, 이를 정확한 용어와 문구로 정리한다. 이 과정에서 발견된 모호하거나 중복된 용어는 제거되거나 명확히 정의된다. 예를 들어, '주문'이라는 개념이 'Order', 'Purchase', 'Transaction' 등 여러 용어로 혼용된다면, 그 중 가장 정확한 하나를 선택하고 그 의미와 사용 조건을 명시한다.

이 언어는 단순한 용어집을 넘어서, 도메인의 복잡한 규칙과 관계를 표현하는 문장 구조까지 포함한다. "주문은 최소 한 개 이상의 품목을 가져야 한다" 또는 "확정된 주문은 취소될 수 없다"와 같은 비즈니스 규칙은 유비쿼터스 언어의 일부가 되어 코드의 도메인 모델에 직접 반영된다. 결과적으로 소프트웨어의 클래스, 메서드, 변수의 이름은 모두 이 공통 언어에서 비롯되며, 이는 코드를 읽는 것만으로도 비즈니스 로직을 이해할 수 있게 만든다.

유비쿼터스 언어를 효과적으로 구축하고 유지하려면, 이를 문서화하고 팀원 모두가 쉽게 접근할 수 있도록 해야 한다. 또한 언어는 고정된 것이 아니라 도메인에 대한 이해가 깊어짐에 따라 진화하며, 이에 맞춰 설계와 코드도 함께 리팩토링되어야 한다. 이렇게 함으로써 소프트웨어는 항상 최신의 도메인 지식을 반영하는 살아있는 모델이 된다.

제한된 컨텍스트는 도메인 주도 설계에서 특정 하위 도메인 내에서 유비쿼터스 언어가 명확한 의미와 경계를 가지는 구체적인 경계를 정의한다. 복잡한 소프트웨어 시스템은 하나의 통일된 모델로 표현하기 어려운 여러 하위 도메인으로 구성된다. 제한된 컨텍스트는 이러한 각 하위 도메인에 대해 명확한 경계를 설정하여, 그 안에서만 모델이 일관되고 모호하지 않게 유지되도록 한다.

예를 들어, 전자상거래 시스템에서 '상품'이라는 용어는 재고 관리 컨텍스트와 카탈로그 컨텍스트에서 서로 다른 의미와 속성을 가질 수 있다. 재고 관리 컨텍스트에서는 SKU, 재고 수량, 창고 위치 등이 핵심 속성이다. 반면, 카탈로그 컨텍스트에서는 상품명, 설명, 가격, 이미지 URL 등이 중요하다. 하나의 거대한 '상품' 모델로 두 관심사를 모두 포함하면 모델이 복잡해지고 유지보수가 어려워진다. 따라서 두 개의 별도 제한된 컨텍스트를 정의하고, 각 컨텍스트 내에서 '상품'에 대한 고유한 모델을 발전시키는 것이 효과적이다.

제한된 컨텍스트 간의 통신은 명시적인 메커니즘을 통해 이루어진다. 가장 일반적인 통합 방식은 다음과 같다.

이러한 경계를 명확히 함으로써 시스템의 복잡성을 관리 가능한 단위로 분해하고, 각 부분의 독립적인 개발과 진화를 가능하게 한다. 제한된 컨텍스트는 대규모 팀 조직과도 밀접한 관련이 있으며, 하나의 팀이 하나의 제한된 컨텍스트를 책임지는 것이 이상적인 구조로 간주된다[2].

엔티티는 도메인 모델 내에서 고유한 식별성을 가지는 객체이다. 엔티티의 생명주기 동안 속성은 변경될 수 있지만, 그 정체성을 정의하는 식별자는 변하지 않는다. 예를 들어, '고객' 엔티티는 이름이나 주소가 바뀌더라도 고객 번호라는 식별자로 동일한 객체임을 추적한다. 이 식별성은 두 엔티티의 모든 속성 값이 동일하더라도 서로 다른 존재로 구분하는 근간이 된다.

반면, 값 객체는 식별성보다는 그 자체의 속성에 의해 정의되는 객체이다. 값 객체는 불변성을 가지는 것이 일반적이며, 속성 값이 같으면 서로 교환 가능한 것으로 간주한다. '주소'나 '금액'과 같은 개념이 값 객체의 전형적인 예이다. 주소는 도로명, 번지, 우편번호로 구성되며, 이 값들이 모두 같다면 두 주소는 논리적으로 동일한 것으로 판단한다. 값 객체는 엔티티의 속성으로 포함되거나, 다른 값 객체의 일부가 될 수 있다.

두 개념의 차이는 아래 표로 정리할 수 있다.

설계 시 엔티티와 값 객체를 올바르게 구분하는 것은 모델의 명확성과 무결성을 높이는 데 중요하다. 값 객체를 적극적으로 사용하면 불필요한 식별자 관리 부담을 줄이고, 도메인의 개념을 더 순수하게 표현할 수 있다. 예를 들어, '송장 주소'를 별도의 엔티티가 아닌 값 객체로 모델링하면, 주소 자체의 변경은 새로운 값 객체를 생성함으로써 처리하고, 식별자를 관리할 필요가 없어진다.

애그리게이트는 도메인 주도 설계에서 제한된 컨텍스트 내의 엔티티와 값 객체를 하나의 군집으로 묶는 단위이다. 이는 복잡한 도메인 모델 내에서 데이터 변경의 일관성을 보장하고, 모델의 경계를 명확히 정의하는 데 사용된다. 애그리게이트는 하나의 루트 엔티티를 가지며, 이 루트를 통해서만 내부 객체에 접근하고 상태를 변경할 수 있다.

애그리게이트의 주요 규칙은 다음과 같다.

* 루트 엔티티: 각 애그리게이트는 단 하나의 루트 엔티티를 가진다. 이 루트는 고유한 식별자를 가지며, 애그리게이트의 대표자 역할을 한다.

* 일관성 경계: 애그리게이트는 트랜잭션 일관성을 보장해야 하는 범위를 정의한다. 애그리게이트 내부의 모든 불변식은 단일 트랜잭션 내에서 항상 만족되어야 한다.

* 참조 규칙: 외부 객체는 애그리게이트의 루트에만 직접 참조를 가질 수 있다. 내부의 다른 엔티티나 값 객체는 루트를 통해서만 접근 가능하다. 애그리게이트 간 참조는 루트의 식별자를 사용하는 것이 일반적이다.

애그리게이트를 설계할 때는 가능한 한 작게 유지하는 것이 좋다. 이는 트랜잭션 충돌을 줄이고 시스템의 성능과 확장성을 높이는 데 도움이 된다. 예를 들어, '주문' 애그리게이트는 '주문' 루트 엔티티와 '주문 항목' 값 객체들을 포함할 수 있지만, '고객'이나 '상품' 정보는 별도의 애그리게이트로 분리하고 식별자로 참조한다.

도메인 서비스는 엔티티나 값 객체에 속하기 어려운 도메인 로직이나 작업을 캡슐화하는 객체입니다. 이는 특정 애그리게이트에 자연스럽게 속하지 않거나, 여러 애그리게이트를 조정해야 하는 복잡한 비즈니스 규칙을 표현할 때 사용됩니다. 도메인 서비스의 핵심은 상태를 가지지 않고(무상태), 순수한 도메인 로직만을 제공하는 데 있다[3].

주요 사용 사례는 다음과 같습니다.

* 여러 애그리게이트에 걸친 로직: 예를 들어, 한 은행 계좌(애그리게이트)에서 다른 계좌로 자금을 이체하는 작업은 출금과 입금이라는 두 개의 별도 애그리게이트를 변경하고, 일관성 규칙을 적용해야 합니다. 이 로직은 '이체 서비스'라는 도메인 서비스에 위치하는 것이 적합합니다.

* 외부 시스템과의 상호작용을 추상화: 도메인 관점에서 필요한 계산(예: 세금 계산, 배송비 계산)이 외부 시스템에 의존할 때, 그 상호작용 인터페이스를 도메인 서비스로 정의합니다. 실제 구현은 인프라 계층에서 제공합니다.

* 순수한 계산 또는 변환 로직: 복잡한 알고리즘 또는 정책(예: 할인 정책 평가, 신용 점수 계산)이 값 객체로 표현하기에 너무 복잡할 때 사용됩니다.

도메인 서비스를 설계할 때는 엔티티나 값 객체로 표현할 수 있는지 먼저 고려해야 합니다. '고객'이나 '주문'과 같은 명사적 개념은 엔티티가 적합하며, '송금하기'나 '계산하기'와 같은 동사적 개념이나 프로세스가 도메인 서비스 후보가 됩니다. 서비스의 인터페이는 도메인 계층에 정의되며, 구현은 도메인 계층이나 인프라 계층에 위치할 수 있습니다. 이를 통해 도메인 모델은 외부 시스템의 구체적 세부 사항에 의존하지 않고 핵심 비즈니스 개념에 집중할 수 있습니다.

리포지토리 패턴은 도메인 모델과 데이터 저장소(주로 데이터베이스) 사이의 매개체 역할을 하는 객체를 정의하는 패턴이다. 이 패턴은 데이터 접근 로직을 캡슐화하여 도메인 계층이 인프라스트럭처 세부 사항에 의존하지 않도록 한다. 리포지토리는 도메인 객체의 컬렉션을 관리하는 것처럼 동작하며, 도메인 계층에서는 객체를 저장하거나 조회하는 구체적인 방법을 알 필요가 없다.

리포지토리의 주요 책임은 애그리게이트 루트 객체의 영속성을 관리하는 것이다. 일반적으로 제공하는 인터페이스 메서드에는 findById, save, delete 등이 포함된다. 리포지토리는 도메인 객체를 데이터베이스의 레코드 형태로 저장하거나, 반대로 질의 결과를 도메인 객체로 재구성하여 반환한다. 이를 통해 도메인 계층은 순수한 비즈니스 로직에 집중할 수 있고, 데이터 저장소를 메모리 데이터베이스에서 관계형 데이터베이스로 변경하더라도 도메인 코드는 영향을 받지 않는다.

리포지토리 구현 시 고려해야 할 중요한 원칙은 영속성 무지를 유지하는 것이다. 즉, 도메인 객체는 자신이 어떻게 저장되고 조회되는지 알지 못해야 한다. 또한, 리포지토리는 제한된 컨텍스트 단위로 정의되며, 한 컨텍스트의 리포지토리가 다른 컨텍스트의 내부 모델을 직접 조회해서는 안 된다. 필요하다면 애플리케이션 서비스를 통해 다른 컨텍스트의 공개된 인터페이스를 이용해야 한다.

리포지토리 패턴을 적용할 때는 객체-관계 매핑 도구의 사용을 고려할 수 있다. 그러나 ORM의 세션 또는 영속성 컨텍스트 개념이 리포지토리의 추상화를 누수시킬 수 있으므로 주의가 필요하다. 예를 들어, 지연 로딩은 도메인 객체가 프록시와 같은 인프라 관심사를 알게 만들어 영속성 무지 원칙을 훼손할 수 있다[4].

도메인 이벤트는 도메인 내에서 발생한 중요한 사건이나 상태 변화를 나타내는 객체입니다. 이는 단순히 시스템의 기술적 로그가 아니라, 비즈니스적 의미를 가진 사건을 의미합니다. 예를 들어, '주문이 접수되었다', '계좌 이체가 완료되었다', '배송이 시작되었다' 등이 도메인 이벤트에 해당합니다. 이벤트는 일반적으로 과거 시제의 동사로 명명되며, 이벤트가 발생한 시점과 관련된 엔티티의 상태 정보를 담고 있습니다.

도메인 이벤트의 주요 목적은 제한된 컨텍스트 내부 또는 다른 컨텍스트 간에 일관성과 느슨한 결합을 유지하는 것입니다. 한 애그리게이트가 자신의 상태를 변경한 후, 관련된 도메인 이벤트를 발행합니다. 그러면 다른 애그리게이트나 도메인 서비스가 이 이벤트를 구독하여 후속 작업을 트리거할 수 있습니다. 이 방식은 시스템 컴포넌트들이 직접 서로를 호출하지 않고도 협력할 수 있게 합니다.

도메인 이벤트를 구현할 때는 일반적으로 다음과 같은 구성 요소를 고려합니다.

이 패턴을 적용하면 비즈니스 규칙이 명확해지고, 시스템의 유연성과 확장성이 향상됩니다. 또한, 이벤트 저장소에 모든 이벤트를 순차적으로 기록함으로써 이벤트 소싱 패턴의 기반이 되거나, 시스템의 상태 변화 내역을 추적하는 감사 로그 역할을 할 수 있습니다.

팩토리는 도메인 주도 설계에서 복잡한 객체 또는 애그리게이트의 생성 로직을 캡슐화하는 도메인 객체 생성 전용 객체 또는 메서드이다. 객체 생성 책임을 명시적으로 분리함으로써 클라이언트 코드가 도메인 객체의 내부 구조나 유효성 검사 규칙을 알 필요 없이 안전하게 객체를 생성할 수 있게 한다.

팩토리의 주요 목적은 생성 로직의 복잡성을 숨기고, 유효한 상태의 객체만을 보장하는 것이다. 특히 다음과 같은 경우에 팩토리를 사용하는 것이 유리하다.

* 객체 생성 과정이 복잡하거나(예: 여러 하위 객체 조립)

* 생성 시 특정 비즈니스 규칙을 적용해야 하거나

* 생성하는 객체의 구체적인 타입을 클라이언트가 결정하지 않아야 할 때

팩토리는 정적 메서드, 별도의 클래스, 또는 애그리게이트 루트 내의 메서드 형태로 구현될 수 있다. 예를 들어, Order 애그리게이트 내에 createOrder라는 정적 팩토리 메서드를 두어 주문 항목 리스트와 고객 정보를 받아 유효성을 검증한 후 새로운 Order 인스턴스를 반환하도록 할 수 있다. 이는 생성자보다 더 표현력이 풍부한 인터페이스를 제공할 수 있다.

팩토리와 리포지토리 패턴은 역할이 명확히 구분된다. 팩토리는 새로운 객체의 생성을 담당하는 반면, 리포지토리는 기존에 영속화된 객체의 조회, 저장, 삭제를 담당한다. 둘 다 도메인 모델의 일관성을 유지하는 데 기여하지만, 그 책임의 영역은 다르다.

계층형 아키텍처는 소프트웨어를 논리적으로 구분된 계층으로 구성하는 전통적인 아키텍처 패턴이다. 도메인 주도 설계에서도 초기 구현 접근법으로 자주 활용된다. 일반적으로 프레젠테이션 계층, 애플리케이션 계층, 도메인 계층, 인프라스트럭처 계층으로 나뉜다. 각 계층은 명확한 책임을 가지며, 의존성은 항상 하위 계층 방향으로 흐른다. 즉, 상위 계층은 하위 계층에 의존하지만, 하위 계층은 상위 계층을 알지 못한다.

도메인 계층은 엔티티, 값 객체, 도메인 서비스 등 핵심 비즈니스 로직과 규칙을 포함한다. 이 계층은 다른 계층에 대한 의존성을 최소화하여 순수한 도메인 개념을 표현하는 데 집중한다. 애플리케이션 계층은 도메인 계층을 조정하여 사용자 요청을 처리하는 작업을 담당한다. 여기에는 트랜잭션 관리, 도메인 이벤트 발행, 보안 검사 등이 포함된다. 프레젠테이션 계층은 사용자 인터페이스를 제공하고, 인프라스트럭처 계층은 데이터베이스 접근이나 외부 서비스 연동과 같은 기술적 관심사를 처리한다.

이 패턴의 주요 장점은 관심사의 분리로 인해 코드의 이해도와 유지보수성이 향상된다는 점이다. 각 계층을 독립적으로 개발하고 테스트할 수 있다. 그러나 단점도 존재한다. 계층 간의 엄격한 규칙이 지켜지지 않으면, 특히 도메인 계층이 인프라스트럭처 계층에 직접 의존하게 되어 도메인 로직이 기술적 세부사항과 뒤섞일 수 있다. 이는 도메인 모델의 순수성을 해치고 테스트를 어렵게 만든다. 또한, 모든 의존성이 단방향이라는 규칙이 복잡한 상호작용을 필요로 하는 현대 애플리케이션에서는 제약이 될 수 있다. 이러한 한계를 보완하기 위해 헥사고날 아키텍처와 같은 더 유연한 아키텍처 패턴이 대안으로 제시된다.

헥사고날 아키텍처는 포트와 어댑터 아키텍처라고도 불리며, 도메인 주도 설계의 구현을 지원하는 아키텍처 패턴이다. 이 아키텍처의 핵심 목표는 도메인 모델을 애플리케이션의 중심에 두고, 외부의 기술적 세부 사항(예: 데이터베이스, 웹 프레임워크, UI)에 대한 의존성을 분리하는 것이다. 이를 통해 비즈니스 로직의 순수성을 유지하고 테스트 용이성과 시스템 유지보수성을 크게 향상시킨다.

이 패턴은 육각형 모양의 다이어그램으로 표현되며, 중앙에 도메인 모델이 위치한다. 도메인 모델 주변에는 외부 세계와의 상호작용을 정의하는 포트가 존재한다. 포트는 인터페이스로, 애플리케이션의 핵심이 제공하거나 필요로 하는 기능을 추상적으로 정의한다. 예를 들어, 데이터를 영구 저장하는 기능은 '저장소 포트'로, 외부 시스템에서 메시지를 받는 기능은 '메시지 수신 포트'로 정의될 수 있다.

포트를 실제 기술로 구현하는 부분은 어댑터이다. 어댑터는 포트 인터페이스를 구체적으로 구현하여 외부 요소와의 연결을 담당한다. 어댑터는 주로 두 가지 유형으로 구분된다.

* 주도형(Driving) 어댑터: 외부에서 애플리케이션을 호출하는 어댑터이다. 예를 들어 REST API 컨트롤러, CLI 인터페이스, 웹 페이지 등이 이에 해당한다.

* 주도되는(Driven) 어댑터: 애플리케이션이 외부를 호출하는 어댑터이다. 예를 들어 데이터베이스 접근 구현체, 외부 API 클라이언트, 메시지 발행 구현체 등이 이에 해당한다.

이 구조의 가장 큰 장점은 의존성 방향이 항상 외부에서 내부(도메인 모델)로 향한다는 점이다. 즉, 데이터베이스, UI, 프레임워크와 같은 외부 기술은 모두 교체 가능한 부품이 된다. 이로 인해 도메인 로직은 외부 변화로부터 보호받으며, 통합 테스트 시 실제 인프라 대신 가짜(Mock) 어댑터를 쉽게 주입하여 도메인 로직만을 격리하여 테스트할 수 있다. 결과적으로 헥사고날 아키텍처는 도메인 주도 설계가 추구하는 도메인 중심의 설계를 실현하는 강력한 기술적 토대를 제공한다.

도메인 모델링 과정은 도메인 주도 설계의 핵심 실천법으로, 복잡한 비즈니스 문제를 소프트웨어 모델로 점진적으로 구체화하는 일련의 활동을 의미한다. 이 과정은 비즈니스 전문가와 개발 팀이 협력하여 유비쿼터스 언어를 정제하고, 제한된 컨텍스트의 경계를 식별하며, 도메인 모델을 반복적으로 구축하고 개선하는 것을 포함한다.

모델링은 일반적으로 도메인 전문가와의 협업 세션을 통해 시작된다. 팀은 비즈니스 프로세스, 규칙, 핵심 개념을 탐구하며 대화를 기록하고, 초기 유비쿼터스 언어의 단어와 문구를 도출한다. 이 단계에서는 화이트보드 스케치, 이벤트 스토밍[7], 간단한 다이어그램 등이 활용되어 추상적인 개념을 시각적으로 표현한다. 목표는 소프트웨어 구조가 아닌, 비즈니스의 본질을 반영하는 개념 모델을 만드는 것이다.

이러한 탐색과 분석을 바탕으로 구체적인 개념 모델링이 이루어진다. 팀은 식별된 개념들을 엔티티, 값 객체, 도메인 서비스 등으로 분류하고, 이들 간의 관계와 불변 조건을 정의한다. 특히 데이터의 일관성과 생명주기를 관리하는 단위인 애그리게이트의 경계를 찾는 것이 중요하다. 이 모델은 즉시 코드로 구현되어 검증되며, 구현 중 발견된 모호함이나 새로운 통찰은 다시 대화와 모델 정제로 이어진다. 따라서 도메인 모델링은 일회성 설계가 아니라, 비즈니스 이해가 깊어짐에 따라 모델도 함께 진화하는 지속적인 학습과 발견의 순환 과정이다.

도메인 주도 설계는 완벽한 설계를 처음부터 완성하기보다는, 지속적인 학습과 발견을 통해 모델을 진화시키는 점진적 접근법을 강조한다. 이 과정에서 리팩토링은 핵심적인 실천법이다. 리팩토링은 코드의 외부 동작을 변경하지 않으면서 내부 구조를 개선하는 작업으로, 유비쿼터스 언어가 더 명확하게 코드에 반영되도록 하고, 제한된 컨텍스트의 경계를 선명하게 다듬는 데 기여한다. 예를 들어, 중복된 로직을 하나의 값 객체로 추출하거나, 명확하지 않은 엔티티의 책임을 도메인 서비스로 분리하는 작업이 여기에 해당한다.

도메인 모델링은 한 번에 끝나는 활동이 아니다. 비즈니스 요구사항에 대한 이해가 깊어지고, 유비쿼터스 언어가 정제됨에 따라 기존 모델은 불완전하거나 부적절해질 수 있다. 따라서 개발 팀은 구현과 피드백 사이의 빠른 사이클을 유지하며 모델을 지속적으로 개선해야 한다. 이 점진적 개선 과정은 설계의 복잡성을 관리하고, 모델이 실제 도메인을 정확하게 반영하도록 보장한다.

리팩토링과 점진적 개선을 효과적으로 수행하기 위해서는 자동화된 테스트 코드가 필수적이다. 특히 도메인 모델의 핵심 로직을 검증하는 단위 테스트는 리팩토링의 안전망 역할을 한다. 테스트가 충분히覆盖되어 있지 않다면, 구조 변경 시 예기치 않은 부작용을 감지하기 어려워 진화보다는 퇴보가 발생할 위험이 있다.

이러한 반복적인 개선 작업은 단순한 코드 정리가 아니라, 도메인에 대한 새로운 통찰을 설계에 즉시 반영하는 도메인 주도 설계의 생명력이다. 최종적으로는 소프트웨어의 유지보수성을 높이고, 변화하는 비즈니스 요구에 더 민첩하게 대응할 수 있는 탄력적인 아키텍처를 구축하는 데 기여한다.