도메인, 도메인 모델?
소프트웨어로 해결하고자 하는 문제 영역을 의미한다.
만약 책을 구매하는 온라인 서점 서비스라면, 온라인 서점이 도메인이 된다.
이 도메인은 다시 주문, 배송, 결제, 회원 등의 하위 도메인으로 분류된다.
따라서 도메인 모델은 소프트웨어 시스템이 해결하려는 현실 세계의 문제(도메인)를 객체 중심으로 추상화한 구조이다.
도메인 모델 패턴
여기서 말하는 도메인 모델이란, 저자 마틴 파울러의 엔터프라이즈 애플리케이션 아키텍처 패턴(위키북스) 책의 도메인 모델 패턴을 의미한다.
표현 영역 : 사용자(or 외부 시스템)의 요청 처리
응용 영역 : 사용자가 요청한 기능 실행. 업무 로직을 구현하지 않고 도메인 계층을 조합해서 기능 실행
도메인 영역 : 시스템이 제공할 도메인 규칙 구현
인프라스트럭처(infrastructure) 영역 : 데이터베이스나 메시징 시스템과 같은 외부 시스템과의 연동 처리
도메인 모델 도출
기존 코드
public class Order{
private OrderState state;
...
private boolean isShiipingChangeable(){
return state == OrderState.PAYMENT_WAITING || state == OrderState.PREPARING;
}
}
요구사항에 제약이나 규칙이 다르게 적용되는 경우가 많다.
예를 들어 아래 요구사항을 기존 코드에 반영하면 아래와 같이 변경될 수 있다.
- 출고를 하면 배송지 정보를 변경할 수 없다.
- 출고 전에 주문을 취소할 수 없다.
- 고객이 결제를 완료하기 전에는 상품을 준비하지 않는다.
요구사항 반영된 코드
public class Order{
private OrderState state;
...
public void changeShippingInfo(){
verifyNotYetShipped();
}
public void cancel(){
verifyNotYetShipped();
this.state = OrderState.CANCELED;
}
private void verifyNotYetShipped(){
if(state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING)
throw new IllegalStateException("already shipped");
}
}
초기에는 배송지 정보 변경에 대한 제약 조건만 파악했기 때문에 '배송지 정보 변경 가능 여부 확인'을 의미하는 isShippingChangeable이라는 메서드명이 사용됐다.
요구사항을 분석하면서 배송지 정보 변경과 주문 취소 둘 다 '출고 전에 가능하다'는 제약이 있음을 알게 되고, 출고 전이라는 의미를 반영하기 위해 verifyNotYetShipped로 메서드명이 변경된다.
이렇게 요구사항 분석을 통해 만들어진 도메인 모델은 실무에서 업무 이해 공유 + 팀 간 소통 + 유지보수 효율화를 위해 문서화하여 공유해야 한다.