도메인 주도 개발1 - 도메인 모델

도메인이란?

개발 입장에서 보면 온라인 서점은 구현해야 할 소프트웨어의 대상이 된다. 온라인 서점 소프트웨어는 온라인으로 책을 판매하는 데 필요한 상품 조회, 구매, 결제, 배송 추적 등의 기능을 제공해야 한다. 이때 온라인 서점은 소프트웨어로 해결하고자 하는 문제 영역, 즉 도메인(domain)에 해당한다.

 

그림 1.1 도메인은 여러 하위 도메인으로 구성된다.

 

한 도메인은 다시 하위 도메인으로 나눌 수 있다. 예를 들어 온라인 서점 도메인은 [그림 1.1]과 같이 몇 개의 하위 도메인으로 나눌 수 있다.

 

카탈로그 하위 도메인은 고객에게 구매할 수 있는 상품 목록을 제공하고, 주문 하위 도메인은 고객의 주문을 처리한다. 혜택 하위 도메인은 쿠폰이나 특별 할일과 같은 서비스를 제공하고, 배송 하위 도메인은 고객에게 구매한 상품을 전달하는 일련의 과정을 처리한다. 한 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능을 제공한다. 예를 들어 고객이 물건을 구매하면 주문, 결제, 배송, 혜택 하위 도메인의 기능이 엮이게 된다.

 

특정 도메인을 위한 소프트웨어라고 해서 도메인이 제공해야 할 모든 기능을 직접 구현하는 것은 아니다. 많은 온라인 쇼핑몰이 자체적으로 배송 시스템을 구축하기보다는 외부 배송 업체의 시스템을 사용하고 배송 추적 정보를 제공하는 데 필요한 기능만 일부 연동한다.

 

그림 1.2 소프트웨어가 도메인의 모든 기능을 제공하진 않는다.

즉 [그림 1.2]와 같이 배송 도메인의 일부 기능은 자체 시스템으로 구현하고, 결제 대행업체를 이용해서 처리할 때가 많다. 또한 도메인 마다 고정된 하위 도메인이 조재하는 것은 아니다. 예를 들어 모든 온라인 쇼핑몰이 고객 혜택을 제공하는 것은 아니며 규모가 크지 않은 소규모 업체는 엑셀과 같은 도구를 이용해서 수작업으로 정산을 처리할 수도 있다.

 

하위 도메인을 어떻게 구성할지 여부는 상황에 따라 달라진다. 기업 고객을 대상으로 대형 장비를 판매하는 곳은 온라인으로 카탈로그를 제공한고 주문서를 받는 정보만 필요할 것이다. 온라인 결제나 배송 추적과 같은 기능을 제공할 필요가 없다. 반면 의류나 액세서리처럼 일반 고객을 대상으로 물건을 판매한다면 카탈로그, 리뷰, 주문, 결제, 배송, 회원 기능 등이 필요할 것이다.

 

도메인 모델

도메인 모델에는 다양한 정의가 존재하는데, 기본적으로 도메인 모델은 특정 도메인을 개념적으로 표현한 것이다. 주문 도메인을 생각해 보자. 온라인 쇼핑몰에서 주문을 하려면 상품을 몇개 살지 선택하고 배송지를 입력한다. 선택한 상품 가격을 이용해서 총 지불 금액을 계산하고, 금액 지불을 위한 결제 수단을 선택한다. 주문한 뒤에도 배송 전이면 배송지 주소를 변경하거나 주문을 취소할 수 있다.

 

객체 기반 주문 도메인 모델

그림 1.3 객체 기반 주문 도메인 모델

 

[그림 1.3]의 모델은 도메인의 모든 내용을 담고 있지는 않지만 이 모델을 보면 주문(Order)은 주문번호(orderNumber)와 지불할 총금액(totalAmount)이 있고, 배송정보(ShippingInfo)를 변경(changeShipping)할 수 있음을 알 수 있다. 또한 주문을 취소(cancel)할 수 있다는 것도 알 수 있다. 도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는 데 도움인 된다.

 

[그림1.3]은 객체를 이용한 도메인 모델이다. 도메인을 이해하려면 도메인이 제공하는 기능과 도메인의 주요 데이터 구성을 파악해야 하는데, 이런 면에서 기능과 데이터를 함께 보여주는 객체 모델은 도메인을 모델링하기에 적합하다.

 

상태 다이어그램을 이용한 주문 상태 모델링

 

그림 1.4 상태 다이어그램을 이용한 주문 상태 모델링

도메인 모델을 객체로만 모델링할 수 있는 것은 아니다.[그림 1.4]는 상태 다이어그램을 이용해서 주문의 상태 전이를 모델링하고 있다. 이 다이어그램을 보면 상품 준비 중 상채에서 주문을 취소하면 결제 취소가 함께 이루어진다는 것을 알 수 있다.

 

도메인 모델을 표현할 때 클래스 다이어그램이나 상태 다이어그램과 같은 UML 표기법만 사용해야 하는 것은 아니다. 관계가 중요한 도메인이라면 그래프를 이용해서 도메인을 모델링할 수 있다. 계산 규칙이 중요하다면 수학 공식을 활용해서 도메인 모델을 만들 수 도 있다. 도메인을 이해하는데 도움이 된다면 표현 방식이 무엇인지는 중요하지 않다.

 

도메인 모델은 기본적으로 도메인 자체를 이해하기 위한 개념 모델이다. 개념 모델을 이용해서 바로 코드를 작성할 수 있는 것은 아니기때문에 구현 기술에 맞는 구현 모델이 따로 필요하다. 개념 모델과 구현 모델은 서로 다른 것이지만 구현 모델이 개념 모델을 최대한 따르도록 할 수는 있다. 예를 들어 객체 기반 모델을 기반으로 도메인을 표현했다면 객체 지향 언어를  이용해 개념 모델이 가깝게 구현할 수 있다. 비슷하게 수학적인 모델을 사용한다면 함수를 이용해서 도메인 모델과 유사한 구현 모델을 만들 수 있다.

 

💡 tip) 하위 도메인과 모델

도메인은 다수의 하위 도메인으로 구성된다. 각 하위 도메인이 다루는 영역은 서로 다르기 때문에 같은 용어라도 하위 도메인마다 의미가 달라질 수 있다. <카탈로그> 도메인의 <상품>이 상품 가격, 상세 내용을 담고 있는 정보를 의미한다면 <배송> 도메인의 <상품>은 고객에게 실제 배송되는 물리적 상품을 의미한다.

도메인에 따라 용어 의미가 결정되므로 여러 하위 도메인을 하나의 다이어그램에 모델링하면 안된다. <카탈로그>와<배송> 도메인 모델을 구분하지 않고 하나의 다이어그램에 함께 표시한다고 가정해 보자. 이 경우 다이어그램에 표시한 <상품>은 카탈로그-상품과 배송-상품이 중복되기 때문에, 각각 <상품>에 의미를 이해하는 데 방해가된다.

모델의 각 구성요서는 특정 도메인으로 한정할 때 비로소 의미가 완전해 지기 때문에 각 하위 도메인마다 별도로 모델을 만들어야 한다. 결과적으로 카탈로그 하위 도메인 모델과 배송 하위 모델을 따로 만들어야 한다는 것을 뜻한다.

 

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

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

도메인 주도 개발 시작하기