1장 도메인 모델 시작하기

도메인이란?

• 현실 세계에 있는 사물이나 현상 등을 소프트웨어로 해결하고자 하는 문제 영역
• 한 도메인은 다시 하위 도메인으로 나눌 수 있다.

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

• 제품 개발과 관련된 전문가, 관계자, 개발자가 같은 지식을 공유하고 직접 소통할수록 도메인 관계자가 원하는 제품을 만들 가능성이 높아진다.

개발자는 요구사항을 이해할 때 왜 이런 기능을 요구하는지 또는 실제로 원하는게 무엇인지 생각하고 전문가와 대화를 통해 진짜로 원하는 것을 찾아야 한다. → 서로의 이해관계를 일치시키는게 중요한 것 같긴 함 ㄹㅇ

도메인 모델

• 특정 도메인을 개념적으로 표현한 것
• 도메인 자체를 이해하기 위한 개념 모델이므로 클래스 다이어그램, 상태 다이어크램과 같은 UML 표기법만 사용해야 하는 것은 아님

개념 모델과 구현 모델

• 개념 모델 : 순수하게 문제를 분석한 결과물이다.
  • 데이터베이스, 트랜잭션 처리, 성능, 구현 기술과 같은 것을 고려하고 있지 않기 때문에 실제 코드를 작성할 때 개념 모델을 있는 그대로 사용할 수 없다.
• 프로젝트 초기에 완벽한 도메인 모델을 만들더라도 결국 도메인에 대한 새로운 지식이 쌓이면서 모델을 보완하거나 변경하는 일이 발생한다.
• 따라서 처음에는 전반적인 개요를 알 수 있는 수준으로 개념 모델 작성 후 도메인에 대한 전체 윤곽을 이해하는 데 집중하고, 구현하는 과정에서 개념 모델을 구현 모델로 점진적으로 발전시켜 나가야 한다.

문서화

• 전반적인 기능 목록이나 모듈 구조, 빌드 과정은 코드를 보고 직접 이해하는 것보다 상위 수준에서 정리한 문서를 참조하는 것이 소프트웨어 전반을 빠르게 이해하는데 도움이 된다. 전체 구조를 이해하고 더 깊게 이해할 필요가 있는 부분을 코드로 분석해 나가면 됨
• 단순히 코드를 보기 좋게 작성하는 것뿐만 아니라 도메인 관점에서 코드가 도메인을 잘 표현해야 비로소 코드의 가독성이 높아지고 문서로서 코드가 의미를 갖게됨

엔티티와 밸류

엔티티

• 식별자를 가짐

밸류(VO)

• 하나의 개념을 표현하고 있음

public class Receiver {
	private String name;
	private String phoneNumber;
	
	...
	
}

• 의미를 명확하게 표현하기 위해 밸류 타입을 사용함

// price와 amounts는 '돈'을 의미하지만 Value 타입이 아니므로 의미가 명확히 전달이 안됨 
public class OrderLine {
	private int price;
	private int quantity;
	private int amounts;
	
	...
}

// 명확히 전달이 됨
public class OrderLine {
	private Money price;
	private int quantity;
	private Money amounts;
	
	...
}

• 식별자를 위한 밸류 타입을 사용해서 의미가 잘 드러나도록 할 수 있음

// OrderNo 타입 자체로 id가 주문번호임을 알 수 있다.
public class Order {
	private OrderNo id;
	
	...
}

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

• 에릭 에반스는 DDD에서 언어의 중요함을 강조하기 위해 유비쿼터스 언어라는 용어를 사용함
• 전문가, 관계자, 개발자가 도메인과 관련된 공통의 언어를 만들고 이를 대화, 문서, 도메인 모델, 코드, 테스트 등 모든 곳에서 같은 용어를 사용함
• 소통 과정에서 발생하는 용어의 모호함을 줄일 수 있고 개발자는 도메인과 코드 사이에서 불필요한 해석 과정을 줄일 수 있다.

Q1. 팀 내 도메인 관계자가 없다면 DDD를 적용하기 어려울까? (꼭 도메인 관계자가 있어야 DDD를 적용할 수 있을까?)