Chapter 1. 도메인 모델 시작

도메인

👀  도메인이란 ?

- 소프트웨어로 해결하고자 하는 문제 영역

• 온라인 책을 판매하는 서점 시스템을 구현하고 할 때, 도메인과 하위 도메인은 아래와 같이 분류할 수 있음
  • 도메인 : 온라인 서점
  • 하위 도메인 : 회원, 상품, 주문, 결제, 배송, 정산, 문의 등
• 한 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능을 제공
  • 물건 구매 : 주문, 결제, 배송, 정산
• 특정 도메인을 위한 소프트웨어라고 해서 도메인이 제공해야 할 모든 기능을 직접 구현하는 것은 아님
  • 외부 PG, 외부 채팅 솔루션
• 도메인 마다 고정된 하위 도메인이 항상 존재하지는 않음
  • 도메인을 제공할 대상에 따라 달라지기도 함

 

도메인 모델

👀  도메인 모델이란?

- 특정 도메인을 개념적으로 표현한 것이고, 도메인 자체를 이해하기 위한 개념 모델

• 도메인의 모든 내용을 담고 있지는 않지만, 여러 개발자들이 동일한 모습으로 도메인 이해 및 도메인 지식을 공유하는데 도움이 됨
• 도메인을 이해하기 위해서 표현방식은 다양할 수 있음

 

도메인 모델 종류 예시

• 클래스 다이어그램 : 기능과 데이터를 함께 보여줌

클래스 다이어그램

 

• 상태 다이어그램 : 특정 도메인의 상태전이를 나타냄

상태 다이어그램

 

도메인 모델  패턴

👀  도메인 모델 패턴이란?

-  도메인 규칙을 객체 지향 기법으로 구현하고, 해당 코드를 도메인 계층에 위치시킴

• Presentation(표현)
  • 사용자의 요청을 처리하고 사용자에게 정보를 보여줌
• Application(응용)
  • 사용자가 요청한 기능을 실행
  • 업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행
• Domain(도메인)
  • 시스템이 제공할 도메인의 규칙을 구현
• Intrastructure(인프라스트럭쳐)
  • 외부 시스템과의 연동을 처리(DB, Messaging 등)

 

 

EX) 주문에 관한 도메인 모델 패턴을 적용한 코드 (요건 : 출고 전 배송지 변경 가능)

public class Order {
	private OrderStatus status;
	private ShippingInfo shippingInfo;

    //출고 전에 배송지를 변경할 수 있음 (대기 중 : PAYMENT_WAITING, 준비 중 : PREPARING)
	public void changeShippingInfo(ShippingInfo newShippingInfo) {
		if (!status.isShippingChangeable()) {
			throw new IllegalStateException();
		}
        
		this.shippingInfo = newShippingInfo;
	}
}

public enum OrderStatus {
	PAYMENT_WAITING {
		public boolean isShippingChangeable() {
			return true;
		}
	},
	PREPARING {
		public boolean isShippingChangeable() {
			return true;
		}
	},
	
	SHIPPED, DELIVERING, DELIVERY_COMPLETED;

	public boolean isShippingChangeable() {
		return false;
	}
}

 

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

 

도메인 모델 작성 유의사항

👀  처음에는 개요 수준의 개념 모델을 작성하여 도메인에 대한 전체 윤곽을 이해하는데 집중하고, 구현하는 과정에서 개념 모델을 구현 모델로 점진적으로 발전

• 개념 모델을 만들때 처음부터 완벽하게 도메인을 표현하는 모델을 만드는 시도를 할 수 있지만 실제로 이는 불가능에 가까움
• 소프트웨어를 개발하는 동안 도메인을 점점 더 이해하게 되기 때문에, 시간이 지나감에 따라 모델을 수정하는 경우가 많기 때문 (지식이 쌓이면서 완전히 다른 의미로 해석되어지는 상황도 존재)

 

도메인 모델 도출

👀  도메인을 모델링할 때 기본이 되는 작업은? 

-  요구사항으로 부터 아래의 요소들을 찾아야함
1. 핵심 구성요소
2. 규칙
3. 기능

• 요구사항을 통해 제공해야 하는 기능을 도출 가능
  • 출고 상태로 변경
  • 배송지 정보 변경
• 요구사항을 통해 특정 항목이 어떤 데이터로 구성되어야 하는지 알 수 있음
  • 한 상품을 한개 이상 주문
  • 각 상품의 구매 가격 합 = (상품 가격 * 구매 개수)
• 요구사항을 통해 각 항목간의 관계를 알 수 있음
  • 주문은 최소 한 종류 이상의 상품을 포함 해야 함
• 요구사항에 따라 특정 조건이나 상태에 따라 제약이 규칙이 달리 적용되는 경우
  • 출고를 하면 배송지 정보를 변경할 수 없음
  • 출고 전에 주문을 취소할 수 있음
  • 고객이 결제 완료하기 전에는 상품을 준비하지 않음

 

도메인 모델 문서화 및 공유

👀 전반적인 기능 목록이나 모듈 구조는 상위 수준에서 정리된 문서를 참조하는 것이 소프트웨어 전반을 빠르게 이해 하는데 도움

더 깊게 이해가 필요가 있는 부분은 코드로 분석하고, 도메인 지식이 잘 묻어나도록 코드 자체도 문서화의 대상

 

엔티티와 밸류

👀 모델은 크게 엔티티와 밸류로 구분

분류	DTO	VO	Entity
정의	각 계층간 데이터 전송	값 표현용	DB 테이블 매핑용
식별자 포함 여부	X	X	O
상태 변경 가능 여부	가변 / 불변	불변	가변 / 불변
Business 로직 포함 여부	X	O	O
Getter 포함 여부	O	O	O
Setter 포함 여부	O	X	O
equals & hashCode 구현 여부	X	O	O

DTO

• 각 계층간 데이터 교환을 위한 객체
• Business 로직은 포함하지 않음
• getter / setter 모두 가질 수 있음

VO

• 개념적으로 완전한 하나를 표현할 때 사용
  • 우편번호, 주소, 상세주소 → 주소 (묶어서 표현)

public class ShippingInfo {
    ...
    private Address address;
    ...
}

public class Address {
	private String postalCode;
	private String address;
	private String addressDetail;
}

• 보다 명확하게 표현할 수 있게되고, 코드의 가독성도 올라감
  • 식별자의 의미를 보다 명확하게 명시하기 위해서 사용 

public class Order {
    private OrderNo id;
    
   ...
   
   public OrderNo getId() {
      return id;
   }
}

• 임의의 두 VO의 주소가 달라도, 내용이 동일하다면 두 VO 는 동일하다고 판단
  • equals / hashCode를 구현

Entity

• 각 Entity 는 고유한 식별자를 가지고 있음
  • 생성방법
    • UUID
    • 특정한 규칙 : 현재 시간과 다른 값을 조합하여 사용
    • 값 직접 입력 : 회원 ID, Email
    • 일련번호 : DB Auto Increment
• 임의의 두 Entity의 식별자가 같으면 두 Entity는 동일하다고 판단
  • equals / hashCode를 식별자를 기준으로 구현

도메인 모델에 Setter를 추가한다면?

• 도메인의 핵심 개념이나 의도를 코드에서 사라지게 함
• 도메인 객체를 생성할 때 완전한 상태가 아닐수도 있게 만듬
  • 도메인 객체가 불완전한 상태로 사용되는것을 막으려면 생성시점에 필요한 것을 모두 전달해줘야 함

 

📕 equals / hashCode 란?

* equals : 두개의 객체가 내용이 같은지 확인
→ 두 Object == 비교를 넘어, 값이 같은지 비교하려면 equals()를 @Override

* hashCode : 두개의 객체가 같은 객체인지 확인
→ equals()가 true인 두 Object를 HashMap에 put을 할 때 동일한 Key로 인식하고 싶은 경우에 hashCode()를 @Override

 

도메인 용어

👀 도메인 용어를 코드에 반영하지 않으면?

- 개발자가 코드의 의미를 해석해야 하는 부담이 생김

// BAD
public enum OrderStatus {
    STEP1, STEP2, STEP3, STEP4 ..
}

// GOOD
public enum OrderStatus {
    PAYMENT_WAITING, PREPARING, SHIPPED, DELIVERING ..
}

• 각각의 STEP이 어느 상태를 나타내는지 직관적으로 보이지 않아 파악이 힘듬
• 파악하더라도 그 상태로 매번 머릿속으로 변환하는 과정이 추가
• 도메인 용어를 코드에 직접 사용해서 이런 불필요한 과정을 줄이고, 코드가 바로 이해될 수 있도록 해주는 것이 좋음

---

최범균 작가님의 DDD START! 1장을 요약했습니다.