DDD (r1)

도메인은 소프트웨어가 해결하고자 하는 특정 비즈니스 분야나 문제 영역을 가리킨다. 예를 들어, 은행 시스템의 도메인은 '금융'이 되고, 온라인 쇼핑몰의 도메인은 '전자상거래'가 된다. 도메인은 단순히 기술적인 기능의 집합이 아니라, 해당 분야의 전문 지식, 규칙, 프로세스, 용어를 모두 포함하는 복합적인 개념이다. 따라서 도메인을 이해한다는 것은 해당 비즈니스가 어떻게 운영되고, 어떤 문제를 직면하며, 어떤 가치를 창출하는지를 깊이 있게 파악하는 것을 의미한다.

도메인은 보통 더 작고 관리 가능한 하위 도메인으로 분해될 수 있다. 예를 들어 전자상거래 시스템은 '주문 처리', '결제', '배송', '재고 관리', '고객 서비스'와 같은 핵심 하위 도메인으로 구성된다. 각 하위 도메인은 비즈니스에서의 중요도와 복잡도에 따라 다음과 같이 분류될 수 있다.

도메인 중심 설계의 출발점은 바로 이 도메인과 하위 도메인을 식별하고, 그 복잡성에 맞춰 소프트웨어의 구조와 의사소통 방식을 정렬하는 데 있다. 개발팀은 도메인 전문가(비즈니스 담당자)와 긴밀히 협력하여 도메인 지식을 습득하고, 이를 소프트웨어 모델로 정제해야 한다. 이 과정에서 생성된 모델은 단순한 데이터 구조가 아니라, 비즈니스 규칙과 행동을 캡슐화한 살아있는 지식의 표현이 된다.

유비쿼터스 언어는 특정 도메인 내에서 모든 이해관계자들이 공통으로 사용하는 정제되고 일관된 언어 체계를 의미한다. 이 언어는 개발자, 도메인 전문가, 프로젝트 관리자 등 모든 구성원이 도메인 지식과 비즈니스 규칙을 논의하고 문서화하며, 최종적으로 소프트웨어 자체(클래스, 메서드, 변수명 등)에 구현할 때까지 동일하게 사용된다. 유비쿼터스 언어의 핵심 목표는 도메인 모델과 소프트웨어 구현 사이의 간극을 해소하고, 팀 내 의사소통의 오류와 모호성을 제거하는 데 있다.

이 언어는 자연스럽게 형성되는 것이 아니라, 도메인 전문가와 개발 팀이 지속적인 대화와 반복적인 모델 정제 과정을 통해 협력적으로 구축한다. 대화 중에 발견된 중요한 개념, 규칙, 프로세스는 명확한 용어로 정의되고, 공식 문서(예: 도메인 모델 다이어그램, 용어집)에 기록된다. 예를 들어, 은행 도메인에서 '계좌 이체'라는 용어가 채택되었다면, 그 정의(출금 계좌, 입금 계좌, 금액, 수수료, 상태 등), 제약 조건(잔액 부족 시 실패), 관련 동사('이체를 신청한다', '이체를 처리한다') 등이 모두 합의되어야 한다.

구현 단계에서 이 합의된 언어는 소스 코드에 직접 반영된다. 클래스명, 메서드명, 모듈명은 모두 유비쿼터스 언어의 용어를 사용하여 명명된다. 이는 코드 자체가 가장 정확한 문서의 역할을 하게 만든다. 도메인 전문가도 일정 수준에서 코드를 검토할 수 있으며, 개발자는 비즈니스 요구사항을 코드로 번역하는 과정에서 의미 전달의 오류를 크게 줄일 수 있다. 유비쿼터스 언어는 정적이지 않으며, 도메인에 대한 이해가 깊어지고 요구사항이 변화함에 따라 함께 진화한다.

바운디드 컨텍스트는 DDD에서 복잡한 도메인을 관리 가능한 단위로 분해하기 위한 핵심적인 전략적 설계 개념이다. 이는 특정 유비쿼터스 언어가 일관되게 적용되고 유효한 명시적인 경계를 정의한다. 하나의 대규모 시스템 내에서도 서로 다른 하위 도메인(예: 주문, 배송, 재고 관리)은 각기 다른 비즈니스 규칙, 용어, 생명주기를 가지며, 바운디드 컨텍스트는 이러한 모델들의 독립성과 명확성을 보장하는 틀을 제공한다.

바운디드 컨텍스트 내에서는 엔티티, 값 객체, 애그리게이트 같은 모델 요소들이 해당 컨텍스트의 유비쿼터스 언어에 따라 매우 정밀하게 설계된다. 예를 들어, '고객'이라는 개념은 '주문' 컨텍스트에서는 배송지와 결제 정보가 중요한 반면, '고객 지원' 컨텍스트에서는 상담 이력과 선호도가 더 중요한 속성이 될 수 있다. 각 컨텍스트는 자신의 모델을 소유하고, 외부와의 상호작용은 잘 정의된 인터페이스를 통해 이루어진다.

컨텍스트 간의 관계와 통합 방식은 컨텍스트 매핑을 통해 관리된다. 일반적인 매핑 패턴으로는 한 컨텍스트가 다른 컨텍스트를 호출하는 고객/공급자 관계, 양방향 종속성을 최소화하는 공유 커널, 또는 완전한 분리를 지향하는 오픈 호스트 서비스 등이 있다. 바운디드 컨텍스트는 물리적 경계(예: 마이크로서비스, 모듈, 패키지)와도 연결될 수 있어, 아키텍처 결정에 직접적인 영향을 미친다.

이 개념을 적용함으로써 개발 팀은 명확한 책임 범위 내에서 작업할 수 있고, 모델의 복잡성이 제어되며, 시스템의 유지보수성과 확장성이 크게 향상된다. 반면, 지나치게 많은 소규모 컨텍스트로 분할하면 통합 복잡도가 급증할 수 있으므로, 도메인 전문가와의 협의를 통해 적절한 규모의 경계를 설정하는 것이 중요하다.

엔티티는 고유한 식별성을 가지는 도메인 객체이다. 엔티티의 생명주기 동안 속성 값이 변경될 수 있지만, 그 고유한 식별자는 변하지 않고 유지된다. 예를 들어, 고객의 이름이나 주소가 바뀌더라도 고객을 식별하는 ID는 동일하게 유지된다. 이 식별성은 객체의 동등성 비교 시 핵심 기준이 된다. 두 엔티티 객체의 모든 속성 값이 같더라도 식별자가 다르면 서로 다른 객체로 판단한다.

반면, 값 객체는 식별성을 가지지 않는 객체이다. 값 객체는 오직 그 속성 값들에 의해 정의되며, 이러한 속성들이 모두 동일하면 두 값 객체는 동일한 것으로 간주한다. 값 객체는 일반적으로 불변성을 가지며, 한 번 생성되면 내부 상태를 변경할 수 없다. 변경이 필요할 경우 새로운 값 객체를 생성하여 대체한다. 통화, 주소, 날짜 범위 등이 값 객체의 전형적인 예이다.

두 개념의 설계 차이는 다음과 같이 정리할 수 있다.

도메인 모델에서 엔티티와 값 객체를 명확히 구분하는 것은 설계의 명확성과 안정성을 높인다. 값 객체를 사용하면 관련 속성들을 의미 있는 단위로 캡슐화할 수 있고, 엔티티의 책임을 줄여 복잡성을 관리하는 데 도움이 된다. 예를 들어, '주문' 엔티티가 '배송지 주소'라는 값 객체를 포함하는 구조는, 주소의 상세 정보가 변경되어도 '주문' 엔티티의 식별성에는 영향을 주지 않는다.

애그리게이트는 도메인 주도 설계에서 엔티티와 값 객체를 하나의 군집으로 묶어 일관성 있는 단위로 다루기 위한 설계 패턴이다. 복잡한 도메인 모델 내에서 데이터의 일관성과 무결성을 보장하는 경계를 정의하는 것이 핵심 목적이다.

하나의 애그리게이트는 하나의 루트 엔티티를 가진다. 이 루트는 애그리게이트의 대표자 역할을 하며, 외부와의 모든 상호작용은 오직 이 루트를 통해서만 이루어진다. 애그리게이트 내부의 다른 객체들은 루트에 직접적으로 연결되며, 루트를 통하지 않고는 접근하거나 변경할 수 없다. 이는 애그리게이트 전체에 걸쳐 불변식[1]을 강제하고, 트랜잭션의 단위를 명확히 하는 데 도움을 준다.

애그리게이트를 설계할 때는 다음 원칙을 준수하는 것이 중요하다.

* 작은 크기 유지: 애그리게이트는 가능한 한 작게 설계하여 성능과 확장성을 높인다.

* 참조 대신 식별자 사용: 다른 애그리게이트를 참조할 때는 객체 참조보다는 해당 애그리게이트 루트의 고유 식별자를 사용한다. 이는 결합도를 낮추고 모델의 경계를 명확히 한다.

* 일관된 변경: 애그리게이트 내부의 모든 변경은 하나의 트랜잭션으로 완료되어야 하며, 애그리게이트 전체가 하나의 단위로 저장되고 로드된다.

적절한 애그리게이트 설계는 도메인 모델의 복잡성을 관리하고, 바운디드 컨텍스트 간의 협력 방식을 단순화하며, 시스템의 성능과 안정성을 크게 향상시킨다.

리포지토리 패턴은 도메인 모델과 데이터 영속성 계층 사이의 매개체 역할을 하는 객체를 정의하는 패턴이다. 이 패턴은 도메인 객체의 저장, 검색, 삭제와 같은 영속성 관련 작업을 추상화하여, 도메인 로직이 데이터 접근 기술(예: SQL, NoSQL, 파일 시스템)에 직접 의존하지 않도록 한다. 리포지토리는 도메인 계층에 속하며, 데이터 접근의 세부 사항은 인프라스트럭처 계층의 구현체에 위임한다.

리포지토리는 주로 애그리게이트 루트 단위로 데이터를 관리한다. 클라이언트는 애그리게이트 루트를 저장하거나 ID를 통해 조회하며, 리포지토리는 내부적으로 필요한 모든 객체의 영속화를 처리한다. 일반적인 리포지토리 인터페이스는 다음과 같은 메서드를 제공한다.

이 패턴을 적용하면 여러 이점이 있다. 첫째, 도메인 코드가 특정 데이터베이스나 ORM 프레임워크에 묶이지 않아 유지보수와 테스트가 용이해진다. 둘째, 메모리 상의 인메모리 리포지토리를 구현하여 단위 테스트를 쉽게 수행할 수 있다. 셋째, 복잡한 쿼리 로직을 리포지토리 구현체 내부로 캡슐화하여 도메인 객체의 응집도를 높인다.

구현 시 주의할 점도 존재한다. 리포지토리는 도메인 객체의 상태를 변경하는 명령을 수행하는 데 초점을 맞추고, 복잡한 조회 기능은 별도의 쿼리 서비스나 CQRS 패턴을 도입하여 분리하는 것이 좋다. 또한, 리포지토리 인터페이스는 도메인 계층에, 그 구현체는 인프라스트럭처 계층에 위치시켜 의존성 방향을 도메인 계층을 향하도록 유지해야 한다.

도메인 서비스는 도메인 모델 내에서 상태를 가지지 않는 오퍼레이션을 캡슐화하는 객체이다. 이는 엔티티나 값 객체에 속하기 어려운 핵심 도메인 로직을 표현하기 위해 사용된다. 이러한 로직은 종종 여러 애그리게이트를 조정하거나, 외부 시스템과의 상호작용을 필요로 하거나, 특정 도메인 객체의 책임으로 보기 어려운 복잡한 계산을 수행한다.

도메인 서비스는 특정 도메인 개념을 모델링하며, 그 이름은 유비쿼터스 언어에서 자연스럽게 도출된다. 예를 들어, '송금 서비스', '요금 계산 서비스', '주문 배정 서비스' 등이 이에 해당한다. 이는 단순한 기술적 유틸리티 클래스와 구분되며, 순수한 도메인 의미를 담고 있어야 한다. 서비스의 메서드는 도메인 객체(엔티티, 값 객체, 다른 도메인 서비스)를 매개변수로 받고, 도메인 객체를 반환하는 것이 일반적이다.

도메인 서비스를 도입할 때는 신중해야 한다. 로직이 명확히 특정 엔티티나 값 객체의 행위나 속성으로 표현될 수 있다면, 해당 객체의 메서드로 구현하는 것이 더 바람직하다. 도메인 서비스는 남용될 경우 애너미크 도메인 모델(약한 도메인 모델)로 이어질 수 있으며, 이는 단순히 데이터 홀더와 절차적 서비스로 구성된 모델을 초래한다.

도메인 이벤트는 도메인 내에서 발생한 중요한 상태 변화나 사건을 의미하는 객체입니다. 이는 시스템의 다른 부분, 특히 동일한 바운디드 컨텍스트 내부나 다른 컨텍스트에 해당 사실을 알리고 후속 조치를 유발하는 데 사용됩니다. 도메인 이벤트는 일반적으로 과거 시제의 명사형으로 명명되며, 예를 들어 주문이_생성됨, 결제가_완료됨, 재고가_부족함 등과 같은 형태를 가집니다.

도메인 이벤트 객체는 이벤트가 발생한 시점, 관련된 엔티티의 식별자, 그리고 해당 사건과 관련된 필요한 데이터를 속성으로 포함합니다. 이벤트는 애그리게이트의 메서드 내에서 생성되고 발행되며, 애그리게이트의 상태를 변경하는 비즈니스 로직의 일부로 간주됩니다. 이벤트를 발행하는 주체는 일반적으로 해당 변화를 일으킨 애그리게이트 루트입니다.

발행된 이벤트는 이벤트 버스나 메시지 브로커와 같은 메커니즘을 통해 구독자에게 전달됩니다. 구독자는 다른 도메인 서비스, 애그리게이트, 혹은 외부 시스템이 될 수 있습니다. 구독자는 수신한 이벤트를 기반으로 추가적인 비즈니스 로직을 실행할 수 있으며, 이를 통해 시스템의 여러 부분이 느슨하게 결합된 상태로 협력하게 됩니다.

도메인 이벤트의 주요 활용 이점과 패턴은 다음과 같습니다.

이벤트 처리는 동기적으로 수행될 수도 있고, 비동기 메시징 큐를 통해 이루어질 수도 있습니다. 이를 통해 시스템의 응답성과 확장성을 개선할 수 있습니다. 또한, 모든 도메인 상태 변화를 이벤트의 연속으로 저장하는 이법트 소싱 패턴은 도메인 이벤트 개념을 극단적으로 적용한 사례입니다.

도메인 모델 내에서 복잡한 객체 생성 로직을 캡슐화하는 패턴이다. 엔티티나 값 객체, 특히 애그리게이트와 같이 생성 과정이 복잡하거나 내부 구조를 숨겨야 하는 객체의 생성을 전담한다. 객체 생성 책임을 명시적으로 분리함으로써 클라이언트 코드를 단순화하고 도메인 모델의 일관성을 유지하는 데 기여한다.

팩토리 패턴은 주로 다음과 같은 상황에서 적용된다. 첫째, 객체 생성에 많은 지식이 필요하거나 여러 단계를 거쳐야 할 때[3]]를 조합하거나 외부 시스템에서 데이터를 가져와 초기화해야 하는 경우]. 둘째, 생성할 객체의 구체적인 타입을 캡슐화하여 클라이언트가 특정 구현에 의존하지 않도록 할 때. 셋째, 애그리게이트 루트를 생성할 때, 그 내부 구성 요소들의 불변식을 보장해야 하는 경우이다.

도메인 모델에서 팩토리는 보통 도메인 서비스나 특정 엔티티의 정적 메서드, 또는 전용 팩토리 클래스로 구현된다. 중요한 원칙은 팩토리가 생성된 객체의 생명주기 관리까지 책임지지 않는다는 점이다. 즉, 생성된 객체의 저장이나 재구성은 리포지토리 패턴의 책임 영역이다. 팩토리는 오직 '새로운' 객체의 유효한 생성에만 집중한다.

팩토리 패턴을 올바르게 사용하면 도메인 지식을 한 곳에 응집시키고, 클라이언트 코드가 도메인의 복잡한 생성 규칙을 알 필요가 없게 만든다. 이는 유비쿼터스 언어를 코드에 반영하는 데도 도움이 되며, 특히 바운디드 컨텍스트 간에 데이터를 전달하여 객체를 생성해야 할 때 유용하게 활용된다.

컨텍스트 매핑은 DDD의 전략적 설계 단계에서 여러 바운디드 컨텍스트 간의 관계와 상호작용 방식을 정의하고 시각화하는 활동이다. 복잡한 시스템은 보통 하나의 바운디드 컨텍스트로 구성되지 않으며, 각 컨텍스트는 서로 다른 팀이 담당하거나 다른 하위 도메인을 표현한다. 컨텍스트 매핑은 이러한 컨텍스트들이 어떻게 연결되어 협력하는지를 명확히 함으로써 시스템의 전체적인 구조와 통합 지점을 이해하는 데 핵심적인 역할을 한다.

매핑은 다이어그램과 함께 각 관계의 유형을 명시적으로 기술하는 문서로 표현된다. 주요 관계 패턴으로는 다음과 같은 것들이 있다[4].

이러한 매핑 작업은 통합의 복잡성을 드러내고, 팀 간 의사소통의 장벽을 식별하며, 시스템의 진화 방향을 결정하는 데 중요한 지침을 제공한다. 예를 들어, 핵심 도메인을 외부 시스템의 변경으로부터 보호해야 한다면 안티코럽션 레이어 패턴을 적용할 수 있다. 컨텍스트 매핑은 정적인 설계가 아니라 시스템과 팀 구조가 변화함에 따라 지속적으로 갱신되어야 하는 살아있는 문서이다.

공유 커널은 서로 다른 바운디드 컨텍스트가 하나의 공통 도메인 모델 부분 집합을 공유하는 설계 패턴이다. 이는 두 컨텍스트 간의 통합을 단순화하고 중복 개발을 방지하기 위해 사용된다. 공유되는 모델은 일반적으로 양쪽 컨텍스트의 핵심적이면서도 안정적인 개념으로 구성되며, 이를 통해 각 팀이 독립적으로 진화하는 동시에 일관성을 유지할 수 있다.

공유 커널을 구현할 때는 몇 가지 중요한 규칙이 따른다. 공유 모델의 변경은 반드시 양쪽 팀의 합의를 거쳐야 한다. 변경 관리 프로세스가 명확하지 않으면 한쪽의 변경이 다른 쪽에 예기치 않은 영향을 미칠 수 있다. 또한, 공유되는 부분은 최소한으로 유지하는 것이 바람직하다. 너무 많은 부분을 공유하면 팀의 자율성이 떨어지고 변경이 어려워져 결합도가 높아지는 문제가 발생한다.

이 패턴은 고객/공급자 관계보다는 긴밀한 협력이 가능한 팀 사이에 적합하다. 두 팀이 물리적으로 가깝거나 동일한 관리 체계 하에 있을 때 효과적이다. 반면, 팀 간 의사소통이 원활하지 않거나 변경 주기가 크게 다를 경우, 공유 커널은 오히려 병목 현상과 충돌의 원인이 될 수 있다.

공유 커널은 신중한 관리 하에 사용될 때 강력한 도구가 되지만, 잘못 적용하면 시스템의 복잡성과 유지보수 비용을 증가시킬 수 있다. 따라서 공유 범위와 변경 관리 프로토콜을 명확히 정의하는 것이 성공적인 적용의 핵심이다.

고객/공급자 관계(Customer/Supplier Relationship)는 두 개의 바운디드 컨텍스트가 상호작용할 때, 하나의 컨텍스트(공급자)가 다른 컨텍스트(고객)에게 명확하게 정의된 서비스나 데이터를 제공하는 협력 패턴이다. 이 관계에서 공급자 측의 출력은 고객 측의 입력으로 사용된다. 핵심은 두 팀 간의 의존 관계가 비대칭적이며, 공급자가 고객의 요구를 충족시키기 위한 협력 관계를 수립한다는 점이다.

이 관계는 공급자 팀이 고객 팀의 요구사항을 우선적으로 고려해야 함을 의미한다. 공급자는 자신의 내부 모델이나 일정에만 집중할 수 없으며, 고객이 필요로 하는 인터페이스와 통합 프로토콜을 설계하고 유지보수하는 책임을 진다. 예를 들어, '주문' 컨텍스트가 '배송' 컨텍스트에 배송 정보를 제공하는 경우, '주문' 팀(공급자)은 '배송' 팀(고객)이 요구하는 데이터 형식과 업데이트 주기에 맞춰 시스템을 조정해야 한다.

성공적인 고객/공급자 관계를 구현하기 위해서는 몇 가지 실천법이 필요하다. 가장 중요한 것은 명확한 계약(Contract)을 수립하는 것이다. 이는 API 명세, 공유되는 데이터 스키마, 또는 서비스 수준 협약(SLA)의 형태를 취할 수 있다. 또한, 두 팀은 지속적인 소통 채널을 마련하고, 공급자는 고객의 피드백을 반영하여 자신의 제품을 개선해야 한다. 때로는 두 팀이 공동으로 통합 테스트를 개발하여 상호작용의 신뢰성을 보장하기도 한다.

이 패턴은 한 컨텍스트가 다른 컨텍스트에 단방향으로 의존할 때 가장 적합하다. 그러나 공급자 팀의 작업이 고객 팀의 개발 속도를 저해하는 병목 현상이 발생하지 않도록 주의해야 한다. 만약 공급자가 고객의 요구를 지속적으로 외면하거나 협력에 실패할 경우, 고객은 안티코럽션 레이어를 도입하거나 관계를 다른 형태로 전환하는 것을 고려하게 된다.

레이어드 아키텍처는 소프트웨어의 관심사를 수평적인 계층으로 분리하여 복잡성을 관리하는 전통적인 아키텍처 패턴이다. DDD에서도 초기 구현 아키텍처로 자주 채택되며, 도메인 계층의 순수성을 보호하는 데 중점을 둔다. 일반적으로 프레젠테이션 계층, 애플리케이션 계층, 도메인 계층, 인프라스트럭처 계층의 네 가지 주요 계층으로 구성된다.

각 계층은 명확한 책임을 가지며, 의존성 방향은 단방향으로 유지된다. 프레젠테이션 계층은 사용자 인터페이스와 요청 처리를 담당한다. 애플리케이션 계층은 유스케이스를 조정하며, 도메인 객체를 조율하고 트랜잭션을 관리하지만 비즈니스 로직 자체는 포함하지 않는다. 핵심 비즈니스 규칙과 엔티티, 값 객체, 도메인 서비스는 모두 도메인 계층에 위치하여 다른 계층에 의존하지 않도록 설계된다. 인프라스트럭처 계층은 데이터 영속화, 외부 시스템 연동 등 기술적 세부 사항을 제공한다.

이 아키텍처의 주요 장점은 관심사의 분리로 인한 코드의 유지보수성과 테스트 용이성이다. 특히 도메인 계층이 기술적 세부사항으로부터 독립적이기 때문에 도메인 모델의 순수성을 유지하고 복잡한 비즈니스 로직에 집중할 수 있다. 그러나 계층 간의 엄격한 분리는 때로 불필요한 간접 계층을 만들어 성능 저하나 코드의 과도한 보일러플레이트를 초래할 수 있다. 또한, 인프라스트럭처 계층에 대한 도메인 계층의 의존성을 제거하기 위해 의존성 역전 원칙을 적용하는 것이 일반적이다[5].

헥사고날 아키텍처는 포트와 어댑터 아키텍처라고도 불리며, 앨리스테어 콕번이 제안한 소프트웨어 설계 접근법이다. 이 아키텍처의 핵심 목표는 도메인 로직을 애플리케이션의 외부 요소(데이터베이스, 사용자 인터페이스, 외부 서비스 등)로부터 분리하여 독립성을 유지하는 것이다. 이를 통해 비즈니스 규칙의 테스트 용이성과 유지보수성을 높이고, 외부 기술 스택의 변경에 영향을 덜 받도록 설계한다.

이 아키텍처는 중앙에 도메인 모델이 위치한 육각형(헥사곤)으로 표현된다. 도메인 모델은 애플리케이션의 가장 중요한 핵심이며, 외부와의 모든 상호작용은 특정 인터페이스인 포트를 통해 이루어진다. 포트는 도메인 계층이 제공하거나 필요로 하는 추상적인 계약이다. 실제로 이 포트를 구현하여 외부 세계와 연결하는 구체적인 구성 요소가 어댑터이다. 어댑터는 주변 장치를 애플리케이션 코어에 연결하는 변환기의 역할을 한다.

어댑터는 주도 방향에 따라 두 가지 유형으로 구분된다. 주도형 어댑터는 애플리케이션 코어가 외부 세계를 호출할 때 사용된다. 예를 들어, 도메인 서비스가 데이터를 저장하기 위해 리포지토리 인터페이스(포트)를 호출하면, 이를 구현한 데이터베이스 어댑터가 실제 SQL 쿼리를 실행한다. 반대로 주도되는 어댑터는 외부에서 애플리케이션 코어로 흐름이 들어올 때 사용된다. 웹 컨트롤러나 메시지 리스너가 사용자의 HTTP 요청이나 메시지를 애플리케이션 서비스가 이해할 수 있는 형태로 변환하여 전달하는 것이 그 예이다.

이 구조의 주요 장점은 의존성 방향이 항상 외부에서 내부(도메인 코어)를 향한다는 점이다. 따라서 도메인 계층은 데이터베이스, 웹 프레임워크, UI 라이브러리 등 어떤 외부 기술에도 의존하지 않는다. 이는 테스트 시 실제 데이터베이스 대신 메모리 구현체를 쉽게 주입할 수 있게 하여 단위 테스트를 용이하게 한다. 또한, 기술 스택의 변경이 필요할 때는 해당 포트에 맞는 새로운 어댑터를 구현하기만 하면 되므로, 코어 비즈니스 로직을 수정하지 않고도 시스템을 진화시킬 수 있다.

이벤트 주도 아키텍처는 DDD의 구현 아키텍처 중 하나로, 시스템의 상태 변화를 도메인 이벤트의 발생과 소비를 중심으로 구성하는 패턴이다. 이 아키텍처에서 애그리게이트는 명령을 처리한 후, 그 결과를 표현하는 불변의 도메인 이벤트를 발행한다. 발행된 이벤트는 메시지 브로커를 통해 비동기적으로 전파되며, 이를 구독하는 다른 바운디드 컨텍스트나 서비스는 자신의 책임에 맞게 이벤트를 처리한다.

이 방식의 핵심 장점은 시스템 구성 요소 간의 느슨한 결합을 가능하게 한다는 점이다. 각 컴포넌트는 특정 이벤트에만 반응하므로, 다른 부분의 내부 구현을 알 필요가 없으며 독립적으로 진화할 수 있다. 또한, 이벤트 로그를 통해 시스템의 모든 상태 변화를 추적할 수 있어, 감사 로그 구성이나 과거 상태로의 복원(이벤트 소싱)과 같은 요구사항을 구현하기에 용이하다.

이벤트 주도 아키텍처는 복잡한 비즈니스 흐름과 여러 독립적인 하위 도메인으로 구성된 대규모 분산 시스템에 특히 적합하다. 그러나 이벤트의 순서 보장, 중복 처리 방지, 디버깅의 복잡성 등 운영상의 새로운 과제를 동반하기도 한다.

DDD는 모든 유형의 프로젝트에 적합한 만능 해결책이 아니다. 그 효과는 프로젝트의 복잡성과 비즈니스 도메인의 성격에 크게 의존한다. 특히 핵심 비즈니스 로직이 복잡하고, 규모가 크며, 지속적으로 진화해야 하는 프로젝트에서 가장 큰 가치를 발휘한다. 반면, 단순한 CRUD(Create, Read, Update, Delete) 위주의 애플리케이션이나 기술적 복잡성만 높은 프로젝트에서는 오히려 과도한 설계 부담을 초래할 수 있다.

DDD가 특히 적합한 프로젝트 유형은 다음과 같다.

반면, 도메인 로직이 거의 없이 단순한 데이터 입출력이 주를 이루는 관리자 페이지나 보고서 생성 도구 같은 프로젝트에서는 DDD의 전술적 패턴(예: 엔티티와 값 객체, 애그리게이트)이 불필요한 오버헤드로 작용할 수 있다. 또한, 프로젝트 초기 단계에서 도메인 전문가와의 긴밀한 협업이 어렵거나, 팀 구성원에게 DDD에 대한 학습 곡선이 부담이 될 경우 성공적인 적용에 어려움을 겪을 수 있다. 따라서 프로젝트를 시작하기 전에 비즈니스 복잡성과 팀의 역량을 정확히 평가하여 DDD 적용 여부를 결정하는 것이 중요하다.

DDD를 성공적으로 적용하면 소프트웨어의 핵심 가치를 높이는 여러 효과를 기대할 수 있다. 가장 큰 효과는 복잡한 비즈니스 문제를 해결하는 소프트웨어의 정확성과 유연성이 향상된다는 점이다. 유비쿼터스 언어를 통해 도메인 전문가와 개발 팀이 같은 언어로 소통하게 되어 요구사항 오해와 전달 오류가 크게 줄어든다. 이는 결국 비즈니스 요구사항을 정확히 반영한 소프트웨어를 만들어낸다. 또한, 바운디드 컨텍스트와 애그리게이트 같은 패턴은 시스템을 명확한 경계와 책임을 가진 모듈로 분리하여, 특정 비즈니스 규칙의 변경이 시스템 전체에 미치는 영향을 최소화한다. 이는 변화에 빠르게 대응할 수 있는 유연한 아키텍처의 기반이 된다.

장기적인 유지보수성과 팀의 생산성 향상도 주요 기대 효과에 속한다. 도메인 지식이 코드 구조에 명시적으로 녹아들어가기 때문에, 새로운 팀원이 프로젝트에 합류했을 때 비즈니스 로직을 이해하고 수정하기가 상대적으로 쉬워진다. 코드의 가독성과 표현력이 증가하여 기술 부채의 누적을 방지하는 데 도움이 된다. 또한, 전략적 설계 기법들을 통해 대규모 팀이 협업할 때 각 하위 도메인 팀이 독립적이고 자율적으로 개발을 진행할 수 있는 환경을 조성한다. 이는 개발 속도를 높이고 병목 현상을 줄이는 효과를 가져온다.

요약하면, DDD는 단기적인 코드 작성의 편의성보다는 장기적인 소프트웨어의 생명력과 비즈니스 가치에 초점을 맞춘다. 복잡성이 핵심인 도메인에서 투자 대비 높은 품질의 소프트웨어를 만들고, 변화하는 시장 요구에 지속적으로 적응할 수 있는 체계를 제공하는 것이 궁극적인 기대 효과이다.

DDD는 복잡한 도메인을 다루는 데 강력한 이점을 제공하지만, 모든 프로젝트에 적합한 만능 해결책은 아니다. 도입을 결정하기 전에 프로젝트의 성격, 팀의 역량, 조직의 문화를 신중히 평가해야 한다. 가장 중요한 고려사항은 프로젝트의 복잡성이다. 단순한 CRUD 위주의 애플리케이션이나 규모가 작은 프로젝트에서는 DDD의 설계 오버헤드가 비용을 초과할 수 있다. DDD는 비즈니스 로직이 복잡하고 규칙이 많은, 즉 도메인 복잡도가 높은 시스템에서 그 진가를 발휘한다.

도입 성공을 위해서는 팀 구성원의 이해와 협력이 필수적이다. 유비쿼터스 언어를 구축하고 유지하려면 도메인 전문가와 개발 팀 간의 지속적이고 긴밀한 소통이 필요하다. 또한, 엔티티, 값 객체, 애그리게이트 같은 개념을 올바르게 식별하고 설계하는 데는 상당한 학습 곡선과 경험이 요구된다. 팀이 객체 지향 설계와 모델링에 대한 충분한 배경 지식을 갖추지 못했다면 구현 과정에서 어려움을 겪을 수 있다.

마지막으로, DDD는 단기적인 구현 속도보다는 장기적인 시스템의 유지보수성, 확장성, 그리고 도메인에 대한 명확한 이해를 통한 코드 품질 향상에 초점을 맞춘다. 따라서 빠른 프로토타이핑이나 시장 출시 속도가 가장 중요한 우선순위인 프로젝트에서는 다른 경량 방법론이 더 적합할 수 있다. 성공적인 도입을 위해서는 DDD의 원칙과 패턴을 교리처럼 따르기보다, 프로젝트의 맥락에 맞게 실용적으로 적용하고 적절히 조정하는 접근이 필요하다.