14장. 애플리케이션 / IDDD (도메인 주도 설계 구현)

개요

---

# 참고

IMPLEMENTING DOMAIN DRIVEN DESIGN (도메인 주도 설계 구현) - 반 버논 지음

 

# 개요

DDD에 대한 기술서적을 읽고 DDD가 무엇인지 이해하고 어떻게 코드에 적용시킬 수 있는지 고민해 보려고 한다.

 

# 14장의 로드맵

• 사용자 인터페이스가 렌더링 할 수 있도록 도메인 모델의 데이터를 제공하는 방법
• 애플리케이션 서비스가 어떻게 구현되는지와 어떤 오퍼레이션을 수행하는지
• 애플리케이션 서비스와 출력 사이의 결합을 제거하는 방법과 클라이언트 타입을 구분하는 방법
• 사용자 인터페이스 안에 여러 모델을 구성해야 하는 이유와 구성하는 방법
• 인프라를 사용해 애플리케이션을 구현하는 기술적 방법

---

14장. 어플리케이션 

도메인 모델은 대개 애플리케이션의 심장부에 있다. 애플리케이션에는 도메인 모델의 개념을 보여주는 사용자 인터페이스가 있고 그 모델상에 사용자가 다양한 행동을 수행하도록 해줄 수 있다. 사용자 인터페이스는 유스케이스 태스크를 조정하고 트랜잭션을 관리하며 필요한 보안 권한의 부여를 담당하는 애플리케이션 단계의 서비스를 활용한다. 그리고 사용자 인터페이스와 해플리케이션 서비스와 도메인 모델은 엔터프라이즈 플랫폼 특정 인프라의 지원에 의존한다. 인프라 구현 세부사항에는 일반적으로 컴포넌트 컨테이너, 애플리케이션 관리, 메시징, 데이터베이스 등의 활용이 포함된다.

 

14-1. 애플리케이션

애플리케이션은 핵심 도메인 모델과 상호 교류하며 이를 지원하기 위해 잘 조합된 컴포넌트의 집합을 의미하기 위해 사용하고 있다. 이는 일반적으로 도메인 모델 그 자체와 사용자 인터페이스 내부적으로 사용되는 애플리케이션 서비스, 인프라적 컴포넌트를 뜻한다. 이 각각의 영역에 어떤 것들이 들어가는지는 애플리케이션마다 다르며, 사용하는 아키텍처가 무엇인지에 따라서도 달라진다.

 

애플리케이션이 자신의 서비스를 프로그램적으로 공개한다면, 사용자 인터페이스가 더 넓어지며 API의 한 유형을 포함하게 된다. 서비스를 공개하는 데는 다양한 방법이 있지만 사람이 인터페이스를 사용하진 않는다. 이런 종류의 인터페이스는 바운디드 컨텍스트의 통합에 논의된다.

 

 

14-2. 도메인 객체의 렌더링

도메인 모델 객체를 사용자 인터페이스상에 렌더링하는 최선의 방법이 무언인지에 관해서 상당한 논쟁이 있고 의견이 분분하다. 사용자 인터페이스는 주로 태스크의 달성에 필요한 수준보다 더 풍부한 데이터를 제공하는 뷰로부터 이점을 얻는다. 사용자가 즉각적인 태스크를 수행하면서 현명한 결정을 내리기 위해 필요한 정보를 제공하기 때문에 추가적인 데이터의 표시가 필요하다. 그러므로 사용자 인터페이스는 종종 다수의 애그리게잇 인스턴스의 속성을 렌더링할 필요가 있다.

 

14-3. 애그리게잇 인스턴스로부터 데이터 전송 객체를 렌더링하기

다수의 애그리게잇 인스턴스를 단일 뷰로 렌더링하는 문제를 해결하는 인기 있는 방법으로 DTO가 있다. DTO는 한 뷰에 표시돼야 하는 모든 특성을 갖도록 설계된다. 애플리케이션 서비스는 리파지토리를 사용해서 필요한 애그리게잇 인스턴스를 읽고, 이를 DTO어셈블러로 위임해 DTO의 특성을 매핑하도록 한다. 따라서 DTO는 렌더링돼야 하는 모든 정보를 운반한다. 사용자 인터페이스 컴포넌트는 개별 DTO특성에 액세스하고 이를 뷰상에 렌더링한다. 

 

이 접근법을 사용하면 리파지토리를 통해 읽기와 쓰기가 모두 수행된다. DTO를 만들어야 하는 애그리게잇의 모든 파트에 DTO어셈블러가 직접적으로 엑세스 하기 때문에 모든 지연 로딩된 컬렉션이 찾아진다는 이점이 있다. 

 

14-4. 애그리게잇 내부 상태를 발행하기 위해 중재자를 사용하자

모델과 그 클라이언트 사이의 촘촘한 결합으로 인해 발생하는 문제를 피하기 위해, 중재자 인터페이스를 설계해 애그리게잇이 내부 상태를 발행하도록 할 수 있다. 클라이언트는 중재자 인터페이스를 구현해 구현자의 객체 참조를 메소드 인수로서 애그리게잇에 전달한다. 그리고 애그리게잇은 그 모습이나 구조를 전현 드러내지 않고 중재자에게 더블 디스패치해서 요청된 상태를 발행한다. 이 방법은 중재자의 인터페이스를 어떤 유형의 뷰 사양과도 엮지 않으며, 필요한 애그리게잇 상태의 렌더링에 집중하도록 해준다.

 

14-5. 도메인 페이로드 객체(DPO)로부터 애그리게잇 인스턴스를 렌더링하라

DTO가 필요하지 않을 때 사용할 수 있는 개선사항을 제시하는 접근법이다. 이는 레더링을 위한 다수의 전체 애그리게잇 인스턴스를 모아서 단인 도메인 페이로드 객체(DPO)로 변환한다. DPO가 DTO와 비슷한 이유로 사용하지만, DPO는 단일 가상 머신 애플리케이션 아키텍처의 장점을 가진다. 

 

이는 개별 특성이 아니라 전체 애그리게잇 인스턴스로의 참조를 담도록 설계된다. 애그리게잇 인스턴스의 클러스터는 간단한 페이로드 컨테이너 객체에 의해 노리적 티어나 계층 사이에 전송될 수 있다. 애플리케이션 서비스는 필요한 애그리게잇 인스턴스를 ㄱ가져오기 위해 리파지토리를 사요하고 DPO를 인스턴스화해서 각가의 참조를 담는다. 프레젠테이션 컴포넌트는 DPO 객체에게 애그리게잇 인스턴스의 참조를 요청하고, 애그리게잇에게 보여주려는 특성을 문의한다.

 

이 접근법은 논리적 계층 간에 데이터의 클러스터를 이동할 수 있도록 객체의 설계를 단순화하는 이점이 있다. DPO는 설계하기가 훨씬 쉽고 메모리 발자국이 작다. 애그리게잇 인스턴스가 어쨌거나 메모리로 읽혀져야 하므로, 우리는 이미 존재한 것들을 활용한다. 

 

# 부정적인 측면 1

고려해야 하는 부정적인 측면도 있다. DTO와의 유사성 때문에 이 접근법 역시 애그리게잇에게 상태를 읽을 수단을 제공해야 할 필요가 있다. 사용자 인터페이스가 모델로 촘촘하게 결합되는 상황을 피하기 위해, DTO 어셈블러가 사용하도록 권장했던 중재자나 더블 디스패치나 애그리게잇 루트 쿼리 인터페이스등을 사용한다. 

 

# 부정적인 측면 2

DPO가 전체 애그리게잇 인스턴스로의 참조를 갖기 때문에 모든 지연로딩된 객체를 늦게 가져온다. 모든 필요한 애그리게잇 속성에 접근해 도메인 페이로드 객체를 생성해야 할 이유는 없다. 애플리케이션 서비스 메소드가 끝날 때 일반적으로 읽기 전용 트랜잭션까지도 커밋되기 때문에, 해결되지 않은 지연로딩 객체를 참조하는 모든 프레젠테이션 컴포넌트는 예외를 발생하게 된다. 지연로딩 문제를 해결하기 위해 즉시로딩 전략을 사용하거나, 도메인 의존성 해결자를 사용할 수 있다. 

 

14-6. 애플리케이션 서비스

사용자 인터페이스는 독립적인 프레젠테이션 모델 컴포넌트를 사용해 여러 바운디드 컨텍스트를 묶어서 하나의 뷰를 구성한다. 사용자 인터페이스는 단일 모델을 렌더링하든 다수의 모델을 구성하든 상관없이, 애플리케이션 서비스와 상호 교류할 가능성이 크다.

 

애플리케이션 서비스는 도메인 모델의 직접적인 클라이언트다. 애플리케이션 서비스의 논리적 위치가 될 수 있는 옵션은 아키텍쳐를 참고하자. 이 서비스는 유스케이스 하나의 흐름당 하나의 서비스 메소드가 해당되도록 태스크를 조정하는 책임이 있다. 애플리케이션 서비스는 ACID 데이터베이스를 사용할 때 모델 상태 변환이 원자적으로 영속되도록 트랜잭션도 함께 제어한다.

 

애플리케이션 서비스가 도메인 서비스와 같다고 생각하면 안된다. 이 둘은 분명 다르다. 애그리게잇, 값 객체, 도메인 서비스를 비롯한 무엇이 됐든, 모든 비즈니스 도메인 로직을 도메인 모델 안에 몰아넣으려고 노력해야 한다. 애플리케이션 서비스를 얇게 유지하면서 오직 모델로 향하는 태스크의 조율에만 사용해야 한다.