[도메인주도개발 - DDD] 도메인 모델 패턴

일반적인 애플리케이션의 아키텍처는 아래 그림과 같이 네 개의 영역으로 구성 된다.

 

 

영역	설명
사용자 인터페이스(UI) 또는 표현	사용자의 요청을 처리하고 사용자에게 정보를 보여준다. 여기서 사용자는 소프트웨어를 사용하는 사람뿐만 아니라 외부 시스템일 수도 있다
응용	사용자가 요청한 기능을 실행한다. 업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행한다.
도메인	시스템이 제공할 도메인 규칙을 구현한다.
인프라스트럭처	데이터베이스나 메시징 시스템과 같은 외부 시스템과의 연동을 처리한다.

 

 

도메인 계층은 도메인의 핵심 규칙을 구현한다.

예를 들어, 주문 도메인의 경우 ‘출고 전에 배송지를 변경할 수 있다’라는 규칙과 ‘주문 취소는 배송 전에만 할 수 있다’라는 규칙을 구현한 코드가 도메인 계층에 위치하게 된다. 이런 도메인 규칙을 객체 지향 기법으로 구현하는 패턴이 도메인 모델 패턴이다.

코드는 아래와 같다.

public class Order {
    private OrderState state;
    private ShippingInfo shippingInfo;
    
    // 배송지 변경
    public void changeShippingInfo(ShippingInfo shippingInfo) {
        if (!this.state.isShippingChangeable()) {
            throw new IllegalStateException("배송지 변경 할수 없습니다. 배송 상태 = " + this.state);
        }
        this.shippingInfo = shippingInfo;
    }
}

 

public enum OrderState {
    // 주문 대기중
    PAYMENT_WAITING {
        public boolean isShippingChangeable() {
            return true;
        }
    },
    // 상품 준비중
    PREPARING {
        public boolean isShippingChangeable() {
            return true;
        }
    },
    SHIPPED, DELIVERING, DELIVERY_COMPLETED;

    public boolean isShippingChangeable() {
        return false;
    }
}

 

위의 코드는 OrderState는 주문 대기 중이거나 상품 준비 중에는 배송지를 변경할 수 있다는 도메인 규칙을 구현하고 있다.

여기서는 배송지 변경 여부 판단을 OrderState의 isShippingChangeable() 메서드를 통해서 처리하고 있지만,

만약 배송지 변경이 가능한지를 판단할 규칙이 주문 상태와 또 다른 정보를 함께 사용한다면 OrderState만으로는 배송지 변경 가능 여부를 판단할 수 없으므로 Order에서 로직을 구현해야 한다.

 

 

중요한 점은 주문과 관련된 중요 업무 규칙을 주문 도메인 모델인 Order나 OrderState에서 구현한다는 점이다.

핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야 할 때 다른 코드에 영향을 덜 주고 변경 내역을 모델에 반영할 수 있게 된다.

 

 

개념 모델과 구현 모델

개념 모델은 순수하게 문제를 분석한 결과물이다. 개념 모델은 데이터베이스, 트랜잭션 처리, 성능, 구현 기술과 같은 것을 고려하고 있지 않기 때문에 실제 코드를 작성할 때 개념 모델을 있는 그대로 사용할 수 없다. 그래서 개념 모델을 구현 가능한 형태의 모델로 전환하는 과정을 거치게 된다.

개념 모델을 만들 때 처음부터 완벽하게 도메인을 표현하는 모델을 만드는 시도를 할 수 있지만 실제로 이것은 불가능하다. 소프트웨어를 개발하는 동안 개발자와 관계자들은 해당 도메인을 더 잘 이해하게 된다. 프로젝트 초기에 이해한 도메인 지식이 시간이 지나 새로운 통찰을 얻으면서 완전히 다른 의미로 해석되는 경우도 있다. 프로젝트 초기에 완벽한 도메인 모델을 만들더라도 결국 도메인에 대한 새로운 지식이 쌓이면서 모델을 보완하거나 변경하는 일이 발생한다.

따라서 처음부터 완벽한 개념 모델을 만들기보다는 전반적인 개요를 알 수 있는 수준으로 개념 모델을 작성해야 한다.
프로젝트 초기에는 개요 수준의 개념 모델로 도메인에 대한 전체 윤곽을 이해하는 데 집중하고, 구현하는 과정에서 개념 모델을 구현 모델로 점진적으로 발전시켜 나가야 한다.