도메인 주도 개발2 - 도메인 모델 패턴

도메인 모델 패턴

 

그림1.5 아키텍쳐 구성

 

표 1.1 아키텍쳐 구성

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

 

 

일반적인 애플리케이션의 아키텍쳐는 [그림 1.5]와 같이 네 개의 영역으로 구성된다. 각  영역의 역할은 [표 1.1]과 같다. 앞서 살펴본 도메인 모델이 도메인 자체를 이해하는 데 필요한 개념 모델을 의미한다면, 이제 살펴볼 도메인 모델은 도메인 모델 패턴을 의미한다. 도메인 모델은 아키텍처 상의 도메인 계층을 객체 지향 기법으로 구현하는 패턴을 말한다.

 

public class Order{
	private OrderState state;
    private ShippingInfo shippingInfo;
    
    public void changeShippingInfo(ShipppingInfo new ShippingInfo){
    	if(!state.isShippingChangeble()){
        	throw new IllegalStateException("can't change shipping in"+ state);
        }
        this.shippingIngo = new ShippingInfo;
    }
    ...
}

public enum OrderState{
	PAYMENT_WAITING{
    	public boolean isShippingChangeable(){
        	return true;
        }
    },
    PREPARING{
    	public boolean isShippingChangeable(){
        	return true;
        }
    },
    SHIPED,DELIVERING,DELIVERY_COMPLETED;
    
    public boolean isShippingCangeable(){
    	return false;
    }
}

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

 

예를들어 위코드를 보자 이 코드는 주문 도메인의 일부 기능을 도메인 모델 패턴으로 구현한 것이다. 주문 상태를 표현하는 OrderState는 배송지를 변경할 수 있는지를 검사할 수 있는 isShippingChangeable()메서드를 제공하고 있다. 코드를 보면 주문 대기 중(PAYMENT_WATING) 상태와 상품 준비 중(PREPAPING) 상태의 isShippingChangeable() 메서드는  true를 리턴한다. 즉 OrderState는 주문 대기 중이거나 상품 준비 중에는 배송지를 변경할 수 있다는 도메인 규칙을 구현하고 있다.

 

실제 배송지 정보를 변경하는  Order 클래스의 changeShippingInfo()메서드는 OrderState의 isShippingChangeable()메서드를 이용해서 변경 가능한 경우에만 배송지를 변경한다.

 

 

public class Order{
    private OrderState state;
    private ShippingInfo shippingInfo;
    
    public void changeShippingInfo(ShippingInfo new Shipping Info){
    	if(!isShippingChangeable()){
        	throw new IllegalStateException("can't change shipping in" + state);
        }
        this.shippingInfo = new ShippingInfo;
    }
    
    private boolean isShippingChageable(){
    	return state == OrderState.PAYMENT_WATING ||
        	state == OrderState.PREPARING;
    }
    ...
}

public enum OrderState{
	PAYMENT_WAITING, PREPARING, SHIPPED, DELIVERING, DELIVERY_COMPLETED;
}

큰 틀에서 보면 OrderState Order에 속한 데이터이므로 배송지 정보 변경 가능 여부를 판단하는 코드를 Order로 이동할 수 있다.  위 코드는 Order클래스에서 판단하도록 수정한 코드를 보여주고 있다.

 

배송지 변경 가능 여부를 판단하는 기능이 Order에 있든 OrderState에 있든 중요한 점은 주문과 관련된 중요 업무 규칙을 주문 도메인 모델인 Order나 OrderState에서 구현한다는 점이다. 핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야 할 때 다른 코드에 영향을 덜 주고 변경 내역을 모델에 반영할 수 있게 된다.

 

💡 tip) 도메인 모델

'도메인 모델'이란 용어는 도메인 자체를 표현하는 개념적인 모델을 의미하지만, 도메인 계층을 구현할 때 사용하는 객체 모델을 언급할 때에도 '도메인 모델'이라는 용어를 사용한다.

 

💡 tip) 개념 모델과 구현모델

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

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

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

 

 

[출처 - 도메인 주도 개발 시작하기: DDD 핵심 개념 정리부터 구현까지, 최범균 저]

https://www.hanbit.co.kr/store/books/look.php?p_code=B4309942517

도메인 주도 개발 시작하기