도메인 주도 개발 시작하기 : 1장 도메인 모델 시작하기

1.1 도메인이란?

• 도메인은 하위도메인으로 나눌 수 있다.

  

  • 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능 제공
    • 고객이 물건 구매 → 주문, 결제, 배송, 혜택 등 하위 도메인 기능 엮이게 된다.
  • 도메인이 제공해야할 모든 기능을 직접 구현하는 것은 아니다.
    • 외부 배송 업체 시스템 이용, 결제 대행업체 이용 등
  • 도메인마다 고정된 하위 도메인이 존재하는 것은 아니다.

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

• 요구사항을 올바르게 이해하지 못하면 요구하지 않은 엉뚱한 기능을 만들게 된다.
  • 수정하려면 많은 노력 필요
  • 요구사항을 올바르게 이해하려면?
    • 전문가와 개발자가 직접 대화
      • 내용을 전파하는 전달자가 많으면 정보 왜곡 및 손실 발생
    • 이해관계자와 개발자도 도메인 지식을 갖춰야한다.

1.3 도메인 모델

• 도메인 모델은 특정 도메인을 개념적으로 표현
  • 여러 관계자들이 동일한 모습으로 도메인을 이애하고 지식을 공유하는데 도움이 된다.
    • 객체 기반 모델, 상태 다이어그램 등
  • 도메인에 따라 용어 의미가 결정되므로 여러 하위 도메인을 하나의 다이어그램에 모델링하면 안 된다.
    • 카탈로그의 상품과 배송의 상품 의미를 동일하게 여기면 이해하는데 방해가 된다.

1.4 도메인 모델 패턴

• 아키텍처 상의 도메인 계층을 객체 지향 기법으로 구현하는 패턴

• 표현 (presentation)
  • 사용자의 요청을 처리하고 사용자에게 정보를 보여준다. 여기서 사용자는
    소프트웨어를 사용하는 사람뿐만 아니라 외부 시스템일 수도 있다.
• 응용 (application)
  • 사용자가 요청한 기능을 실행한다. 업무 로직을 직접 구현하지 않으며 도
    메인 계층을 조합해서 기능을 실행한다.
• 도메인
  • 시스템이 제공할 도메인 규칙을 구현한다.
  • 핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야할 때 다른 코드에 영향을 덜 주고 변경 내역을 모델에 반영
• 인프라스트럭처 (infrastructure)
  • 데이터베이스나 메시징 시스템과 같은 외부 시스템과의 연동을 처리한다.
• 프로젝트 초기에 완벽한 도메인 모델을 만들더라도 결국 도메인에 대한 새로운 지식이 쌓이면서 모델을 보완하거나 변경하는 일이 발생한다.
  • 구현하는 과정에서 개념 모델을 구현 모델로 점진적 발전

1.5 도메인 모델 도출

• 기획서, 유스케이스, 사용자 스토리와 같은 요구사항과 관련자와의 대화를 통해 도메인을 이해하고 이를 바탕으로 도메인 모델 초안을 만들어야한다.
  • 코드로 전체 소프트웨어를 분석하려면 많은 시간을 투자해야하기 떄문에 상위 수준에서 정리한 문서를 참조하는 것이 빠르게 이해하는데 도움된다.

1.6 엔티티와 밸류

• 엔티티
  • 식별자를 가진다.
    • 특정 규칙에 따라 생성
    • UUID or Nano Id
    • 값 직접 입력
    • 일련번호 사용 (시퀀스, DB auto increment)
• 밸류 타입
  • 개념적으로 완전한 하나를 표현할 때 사용

    public class Receiver {
    	private String name;
    	private String phoneNumber;
    	
    	public Receiver(String name, String phoneNumber) {
    		this.name = name;
    		this.phoneNumber = phoneNumber;
    	}
    }

    • Receiver 받는 사람이라는 도메인 개념

      public class Shippinginfo {
      	private Receiver receiver;
      	private Address address;
      }

  • 코드의 의미를 더 잘 이해할 수 있도록 한다.
  • 기존 데이터를 변경하기보다는 변경한 데이터를 갖는 새로운 밸류 객체를 생성하는 방식을 선호

    public OrderLine(Product product, Money price, int quantity) {
    	this.product = product;
    	// 데이터를 복사한 새로운 객체를 생성
    	this.price = new Money (price, getValue());
    	this.quantity = quantity;
    	this.amounts = calculateAmounts();
    }

  • setter 쓰면 참조 투명성 문제를 마주칠 수 있다.
• setter를 지양하자
  • setter를 사용하면 필드값만 변경하고 끝나기 때문에 상태 변경과 관련된 도메인 지식이 코드에서 사라지게 된다.
  • 도메인 객체를 생성할 때 온전하지 않은 상태가 될 수 있다.
  • setter가 private이면 클래스 외부에서 데이터 변경 불가능
  • springboot에서 set 메서드가 아닌 private 필드에 직접 값을 할당하는 기능
    • 리플랙션, 프록시

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

• 코드 작성 시 도메인에서 사용하는 용어를 코드에 반영해야한다.
  • 그렇지 않으면 개발자가 해석하기 힘들다.
• 유비쿼터스 언어
  • 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드 등 모든 곳에서 같은 용어 사용
    • 소통 과정에서 발생하는 용어의 모호함 줄일 수 있다.