[도메인 주도 개발 시작하기] - 1장 도메인 모델 시작하기

1.1 도메인이란?

• 도메인: 소프트웨어로 해결하고자 하는 문제 영역
  ex) 온라인 서점: 온라인으로 책을 판매하는데 필요한 상품 조회, 구매, 결제, 배송 추적 등의 기능
• 한 도메인은 다시 하위 도메인으로 나눌 수 있음
  ex) 카탈로그 → 상품 목록, 주문 → 고객의 주문 처리, 혜택 → 쿠폰이나 특별 할인, 배송 → 상품을 전달하는 과정
  다른 하위 도메인과 연동하여 완전한 기능 제공
• 도메인이 제공해야 할 모든 기능을 직접 구현하는 것은 X
  ex) 외부 배송 업체의 시스템을 사용하며 배송 추적 정보를 제공하는데 필요한 기능만 일부 연동

 

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

• 전문가: 해당 도메인에 대한 지식과 경험을 바탕으로 본인들이 원하는 기능 개발을 요구
• 개발자: 요구사항을 분석하고 설계하여 코드를 작성하며 테스트하고 배포

→ 이러한 과정에서 요구사항은 첫 단추와 같으므로 코딩에 앞서 요구사항을 올바르게 이해하는 것이 중요

 

1.3 도메인 모델

• 도메인 모델: 특정 도메인을 개념적으로 표현한 것
  ex) 온라인 쇼핑몰에서의 주문: 구매할 상품 개수 결정, 배송지 입력, 금액 계산, 결제 수단 선택, 주문 후에도 배송지 주소 변경이나 주문 취소
• 도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는데 도움이 됨
• 객체를 이용한 도메인 모델의 장점: 도메인을 이해하려면 도메인이 제공하는 기능과 도메인의 주요 데이터 구성을 파악해야 하는데, 이런 면에서 기능과 데이터를 함께 보여주는 객체 모델은 도메인을 모델링하기에 적합

 

1.4 도메인 모델 패턴

• 일반적인 애플리케이션 아키텍쳐 구성

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

 

• 책 [엔터프라이즈 애플리케이션 아키텍처 패턴]에서의 도메인 모델: 아키텍처 상의 도메인 계층을 객체지향 기법으로 구현하는 패턴
• 도메인 계층은 도메인의 핵심 규칙을 구현함
  ex) 주문 도메인의 경우 '출고 전에 배송지를 변경할 수 있다', '주문 취소는 배송 전에만 할 수 있다' 등의 규칙을 구현한 코드가 도메인 계층에 위치함
• 도메인 모델 패턴: 도메인 규칙을 객체지향 기법으로 구현하는 패턴 
• 핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야할 때 다른 코드에 영향을 덜 주고 변경 내역을 모델에 반영할 수 있게 됨.

 

1.5 도메인 모델 도출

• 도메인을 모델링할 때 기본이 되는 작업: 모델을 구성하는 핵심 구성요소, 규칙, 기능 찾기
  Order와 관련된 기능을 모델링하는 과정 35p~40p 참고

 

1.6 엔티티와 밸류

도출한 모델은 크게 엔티티와 밸류로 구분할 수 있음

1.6.1 엔티티

• 특징: 식별자를 가짐. 식별자는 엔티티 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 가짐
  ex) 주문 도메인에서 각 주문의 주문번호 → Order가 엔티티가 되며 주문번호를 속성으로 갖게 됨

1.6.2 엔티티의 식별자 생성

엔티티 식별자를 생성하는 방법 4가지

• 특정 규칙에 따라 생성
  ex) 주문 번호, 운송장 번호, 카드번호 등
• UUID(university unique identifier)나 Nano ID와 같은 고유 식별자 생성기 사용
  다수의 개발 언어가 UUID 생성기를 제공하고 있으므로 마땅한 규칙이 없다면 사용해도 됨
  ex) 자바는 java.util.UUID 클래스를 사용해서 생성 가능
• 값을 직접 입력
  ex) 회원의 아이디나 이메일과 같은 식별자(사용자가 직접 입력하는 값이기 때문에 식별자를 중복해서 입력하지 않도록 사전에 방지하는 것이 중요)
• 일련번호 사용
  주로 데이터베이스가 제공하는 자동 증가 기능을 사용
  ex) 포털 사이트에서의 게시글 URL: articleId 파라미터 값을 삽입

1.6.3 밸류 타입

• 밸류 타입은 개념적으로 완전한 하나를 표현할 때 사용
  ex) ShippingInfo 클래스:  Receiver와 Adress타입 46p~48p 참고
• 밸류 타입이 꼭 두 개 이상의 데이터를 가져야하는 것은 아님. 의미를 명확하게 표현하기 위해 사용하는 경우도 있음
  ex) OrderLine 클래스: Money 타입 48p~49p 참고
• 밸류 타입의 장점
  • 밸류 타입을 위한 기능 추가 가능
    ex) Money 타입: 돈계산을 위한 기능 추가 49p 참고
  • 밸류 타입은 코드의 의미를 더 잘 이해할 수 있도록 함 (코드 가독성 향상)
• 밸류 타입은 불변(immutable)으로 구현함: 안전한 코드 작성을 위해
  ex) Money 타입: 50p 참고

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

• 엔티티 식별자는 단순한 문자열이 아니라 도메인에서 특별한 의미를 지니는 경우가 많기 때문에 식별자를 위한 밸류 타입을 사용해서 의미가 잘 드러나도록 할 수 있음
  ex) 주문 번호를 표현하기 위해 Order의 식별자 타입으로 String 대신 OrderNo 밸류 타입 사용

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

• set 메서드는 도메인 핵심 개념이나 의도를 코드에서 사라지게 함
  ex) Order 클래스에 setShippingInfo, setOrderState 메서드를 넣는다고 가정
  • 앞서 changeShippingInfo()가 배송지 정보를 새로 변경한다는 의미를 가졌다면 setShippingInfo() 메서드는 단순히 배송지 값을 설정한다는 것을 의미
  • 앞서 completePayment()가 결제를 완료했다는 의미를 갖는 반면 setOrderState()는 단순히 주문 상태 값을 설정한다는 것을 의미
• 도메인 객체를 생성할 때 온전하지 않은 상태가 될 수 있음
  
• 불변 밸류 타입을 사용하면 자연스럽게 밸류 타입에는 set 매서드를 구현하지 않기에 밸류 타입은 불변으로 구현!

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

도메인 용어를 잘못 설정한 예시

• OrderState에서 결제 대기중, 상품 준비중, 출고 완료됨, 배송중, 배송 완료됨, 주문 취소를 STEP1, STEP2, STEP3, STEP4, STEP5, STEP6으로 설정한다면 기획자나 온라인 쇼핑 도메인 전문가가 개발자와의 업무 회의에서 해석하는 과정을 거쳐야 함
• PAYMENT_WAITING, PREPARING, SHIPPED, DELIVERING, DELRIVERY_COMPLETED와 같이 도메인 용어를 사용해서 OrderState를 구현하면 불필요한 변환 과정을 거치지 않아도 됨
• 이는 코드 가독성을 높여서 코드를 분석하고 이해하는 시간을 줄여줌

유비쿼터스 언어: 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 같은 용어 사용

→ 소통과정에서 발생하는 용어의 모호함을 줄일 수 있고 개발자는 도메인과 코드 사이에서 불필요한 해석 과정을 줄일 수 있음

 

1장을 마무리하며...

백엔드 개발을 함에 있어 스프링과 같은 기술을 공부하는 것 외에도 도메인을 이해하고 효율적으로 구성하기 위한 노력도 필요하다는 것을 알게 되었다. 개발을 진행하기 전 도메인 모델을 확실히 설계하고 가야지 개발에 들어가서 혼란이 없고, 도메인 용어를 모두 이해하기 쉽게 설정해야 다른 관계자들과 소통할 때 효율적으로 대화할 수 있다는 것을 알게되었다. 앞으로 개발을 진행할 때 오늘 학습한 도메인 설계까지 놓치지 않고 해야겠다는 생각이 들었다.