[DDD] 1장. 도메인 모델 시작하기

1. 도메인

1.1 도메인이란

• 도메인: 소프트웨어로 해결하고자 하는 문제 영역
  ex) 온라인 서점 - 도서 검색, 구매, 장바구니, 쿠폰, 결제, 포인트 적립, 배송 추적 등이 구현되어 있음
  ➡️ 개발자: '어케했노...' 즉, 온라인 서점은 개발자에게 소프트웨어로 해결하고자하는 도메인
• 하위 도메인: 큰 도메인에 속한 도메인들.
  ex) 온라인 서점 = 주문+회원+리뷰+정산+배송+...
  ➡️ 각 기능이 하위 도메인으로 존재함.
• 하나의 소프트웨어가 도메인의 모든 기능을 제공하지는 않음. 도메인의 일부 기능은 외부 업체의 시스템을 사용하는 경우가 많음.
• 하위 도메인의 구성은 상황에 따라 달라짐
  ex) b2b인지, b2c인지...

1.2 도메인 전문가와 개발자 간 지식 공유

1) 프로젝트에서의 도메인 전문가와 개발자

• 도메인 전문가: 홍보, 정산, 배송 등 각 도메인에 대한 지식과 경험을 바탕으로 원하는 기능 개발을 요구
• 개발자: 도메인 전문가의 요구사항을 분석하고 설계하여 코드를 작성하며 테스트하고 배포 ➡️ 이때, 개발자가 도메인 전문가의 요구를 제대로 이해하지 못하면 엉뚱한 기능을 만들어내게 됨. 잘못 개발한 기능을 바르게 고치려면 많은 시간과 비용이 들고, 최악의 경우 제품을 만드는데 실패하기도 함. 따라서 개발자는 코딩에 앞서 전문가의 요구사항을 올바르게 이해해야 함.
  

2) 도메인 전문가의 요구사항을 올바르게 이해하는 방법

• 개발자와 전문가가 직접 대화하기
• 도메인에 관련한 지식 갖추기

2. 도메인 모델

1.3 도메인 모델

• 도메인: 특정 도메인을 개념적으로 표현한 것

• 도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는 데 도움이 됨

• 도메인 모델링 방법

  • 객체 모델
    

  • 상태 다이어그램

  • 클래스 다이어그램
    

    		- 꼭 UML 표기법만 사용할 필요는 없음, 필요에 따라 그래프나 수학 공식으로도 표현할 수 있다.

    UML: Unified Modeling Language, 시스템을 모델로 표현해주는 대표적인 모델링 언어. 구조 다이어그램과 행위 다이어그램으로 나눌 수 있음.

➕ 알아두기
하위 도메인이 다루는 영역이 서로 다르므로, 여러 하위 도메인을 하나의 다이어그램에 모델링하면 안 됨.

1.4 도메인 모델 패턴

1.4.1 어플리케이션의 아키텍처

• 구성: user - 표현 / 응용 / 도메인 / 인프라 - DB
  - UI 또는 표현: 사용자의 요청을 처리하고 사용자에게 데이터를 보여줌. 사용자는 사람뿐만 아니라 외부 시스템일 수도 있음.
  - 응용: 사용자가 요청한 기능을 실행함.
  - 도메인: 시스템이 제공할 도메인 규칙을 구현.
  이게 무슨 말이나면... 예를 들어 '출고 전에 배송지를 변경할 수 있다' 라는 규칙이 있다면 이러한 규칙을 구현한 코드가 도메인 계층에 위치하게 되는 것.
  - 인프라스트럭처: 외부 시스템(ex.DB)과의 연동을 처리.
  1.4.2 실습

  # p. 31-32 
  # 주문 도메인의 일부 기능을 도메인 모델 패턴으로 구현

➕ 알아두기
개념 모델은 순수하게 문제를 분석한 결과물. 다른 요소에 대한 고려 없이 오로지 문제만을 분석해두었기 때문에 있는 그대로 사용할 수 없고, 구현 가능한 형태의 모델로 전환해야 함

1.5 도메인 모델 도출

• 구현을 시작하기 위해서는 도메인에 대한 초기 모델이 필요함.

• 도메인 모델링의 기본 작업: 모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾는 것. ➡️ 요구사항에서 출발

  ex) 주문 요구사항

  - 최소 한 종류 이상의 상품을 '주문'
  - 한 상품을 한 개 이상 '주문'
  - '총 주문 금액'은 각 상품의 구매 가격 합을 모두 더한 금액
  - 각 상품의 '구매 가격 합'은 상품 가격에 구매 개수를 곱한 값
  - 주문할 때 '배송지 정보'를 반드시 지정해야 함 
  - '배송지 정보'는 받는 사람 이름, 전화번호, 주소로 구성
  - '출고'를 하면 '배송지를 변경'할 수 없음
  - '출고' 전에 '주문을 취소'할 수 있음
  - 고객이 '결제를 완료'하기 전에는 상품을 준비하지 않음
  ➡️ 주문은 '출고 상태로 변경하기', '배송지 정보 변경하기', '주문 취소하기', '결제 완료하기' 기능을 제공한다는 것을 파악할 수 있음

  - 주문 요구 사항에 따라 Order에 관한 메서드를 추가해보면...

  # p.36
  # 주문 항목이 어떤 데이터로 구성되는지

  - 주문 항목 OrderLine을 표현해보면...

  # p. 36
  # 한 상품을 얼마에 몇개 살지를 담고 있음.

  - Order과 OrderLine의 관계는...

  # p.37

➕ 문서화

• 문서화를 하는 이유: 지식을 공유하기 위함
• 코드 자체도 문서화의 대상이 됨. 도메인 관점에서 코드가 도메인을 잘 표현해야 비로소 코드의 가독성이 높아지고, 문서로서 코드가 의미를 가짐

3. 엔티티와 밸류

1.6 엔티티와 밸류

1.6.1 엔티티

• 엔티티의 특징: 식별자를 가짐
• 식별자: 엔티티 객체마다 가지는 고유한 값. 따라서, 식별자는 중복될 수 없음.
• 실습: 엔티티를 구현한 클래스에 식별자를 이용해서 메서드 구현해보기

  실습 코드

1.6.2 엔티티의 식별자 생성

• 식별자 생성 시점: 도메인의 특징과 사용하는 기술에 따라 달라짐
• 식별자 생성 방식
  • 특정 규칙에 따라 생성: 현재시간+다른 값 조합
    ex. 2023031057329483에서 20230310이 2023/03/10을 의미
  • UUID(Universally Unique Identifier)나 Nano ID와 같은 고유 식별자 생성기 사용 ➡️ java.util.UUID 클래스 사용해서 생성 가능
    ex. 614d34-d253-n463-243290sfkj241과 같은 형식의 문자열
  • 값을 직접 입력
    ex. 회원 ID, email과 같은 값
  • 일련번호 사용: 시퀀스(Oracle)나 DB의 자동 증가 기능(MySQL)을 사용.

1.6.3 밸류 타입

• 개념적으로 완전한 하나를 표현할 때 사용
  ex. 받는 사람 = 이름+주소 ➡️ 데이터 형식은 다르지만 모두 받는 사람을 나타냄
• 실습

# p.47-52 실습 코드

1.6.4 엔티티 식별자와 밸류 타입

• 엔티티 식별자의 실제 데이터는 String과 같은 문자열로 구성된 경우가 많음.
• 도메인에서 특별한 의미를 지니는 식별자를 위한 밸류 타입을 사용해서 의미를 잘 드러나도록 해야 함.
  ex.

# p.53 상단 실습 코드

1.6.5 도메인 모델에 set 메서드 넣지 않기

• get/set 메서드를 습관적으로 추가하는 것은 좋지 않음. 특히 set 메서드는 도메인의 핵심 개념이나 의도를 코드에서 사라지게 함.
• 불변 밸류 타입을 사용하면 자연스럽게 밸류 타입에는 set 메서드를 구현하지 않음. set 메서드를 구현해야 할 특별한 이유가 없는 한, 불변 타입을 장점을 살릴 수 있도록 밸류 타입을 불변으로 구현하기
• 실습

# p.53-55

➕ DTO의 get/set 메서드
DTO: Data Transfer Object, 프레젠테이션 계층과 도메인 계층이 데이터를 서로 주고받을 때 사용하는 일종의 구조체. 오래전에 사용했던 프레임워크에서는 구현 기술을 적용하기 위해서 어쩔 수 없이 DTO에 get/set 메서드를 구현해야 했지만, 요즘 프레임워크는 set 메서드를 만드는 대신 private 필드에 직접 값을 할당함으로써 구현함. 따라서, DTO도 불변 객체가 되어 불변의 장점을 취할 수 있음!

4. 도메인 용어

1.7 도메인 언어와 유비쿼터스 언어

• 코드에서 중요한 도메인의 규칙이 드러나도록 작성해야 함
• 유비쿼터스: 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 같은 용어를 사용하는 것
  ➡️ 소통 과정에서 발생하는 용어의 모호함을 줄일 수 있고, 도메인과 코드 사이에서 불필요한 해석 과정을 줄일 수 있음.
• 도메인 용어는 좋은 코드를 만드는 데 매우 중요한 요소. 하지만 영단어를 사용한다는 점에서 미묘한 뉘앙스를 잘 표현하지 못해서 결과적으로 코드와 도메인이 서로 동떨어지게 됨. 따라서, 알맞은 영단어를 찾기 위해 시간을 들여 찾는 노력이 필요함.