1장 - 도메인 모델 시작하기

도메인

---

도메인은 여러 하위 도메인으로 구성된다.

• 한 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능을 제공
• ex) 고객이 물건을 구매
  • 주문, 결제, 배송, 혜택 하위 도메인의 기능이 엮이게 된다.

특정 도메인을 위한 소프트웨어라고 해서 도메인이 제공해야 할 모든 기능을 직접 구현하는 것은 아니다.

도메인마다 고정된 하위 도메인이 존재하는 것은 아니다.

• 하위 도메인을 어떻게 구성할지 여부는 상황에 따라 달라진다.

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

전문가

• 해당 도메인에 대한 지식과 경험을 바탕으로 본인들이 원하는 기능 개발을 요구

개발자

• 전문가의 요구사항을 분석하고 설계하여 코드를 작성하며 테스트하고 배포한다.
• 요구사항을 올바르게 이해하는 것이 중요하다.

“Garbage in, Garbage out”

• 잘못된 요구사항이 들어가면 잘못된 제품이 나온다.
• 같은 지식을 공유하고 직접 소통할수록 도메인 전문가가 원하는 제품을 만들 가능성이 높아진다.
• 도메인 전문가 만큼은 아니겠지만 이해관계자와 개발자도 도메인 지식을 갖춰야 한다

도메인 모델

---

도메인 모델

• 특정 도메인을 개념적으로 표현한 것.
• 도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는 데 도움이 된다.

객체 모델

모데인을 이해하려면 도메인이 제공하는 기능과 도메인의 주요 데이터 구성을 파악해야 한다.

이런 면에서 기능과 데이터를 함께 보여주는 객체 모델은 도메인을 모델링하기에 적합하다.

도메인 모델은 기본적으로 도메인 자체를 이해하기 위한 개념 모델이다.

• 개념 모델을 이용해서 바로 코드를 작성할 수 있는 것은 아니기에 구현 기술에 맞는 구현 모델이 따로 필요하다.
• 개념 모델과 구현 모델은 서로 다른 것이지만 구현 모델이 개념 모델을 최대한 따르도록 할 수는 있다.

하위 도메인과 모델

• 도메인은 다수의 하위 도메인으로 구성된다.

각 하위 도메인이 다루는 영역은 서로 다르기 때문에 같은 용어라도 하위 도메인마다 의미가 달라질 수 있다.

ex) 카타로그 도메인의 상품 - 상품 가격, 상세 내용을 담고 있는 정보를 의미

배송 도메인의 상품 - 고객에게 실제 배송되는 물리적인 상품을 의미

도메인에 따라 용어 의미가 결정되므로 여러 하위 도메인을 하나의 다이어그램에 모델링하면 안된다.

모델의 각 구성요소는 특정 도메인으로 한정할 때 비로소 의미가 완전해지기 때문에 각 하위 도메인마다 별도로 모델을 만들어야 한다.

도메인 모델 패턴

일반적인 애플리케이션의 아키텍처는 4개의 영역으로 구성된다.

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

도메인 모델은 아키텍처 상의 도메인 계층을 객체 지향 기법으로 구현하는 패턴이다.

• 도메인 계층은 도메인의 핵심 규칙 을 구현한다.
• 도메인 규칙을 객체 지향 기법으로 구현하는 패턴이 도메인 모델 패턴 이다.

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

도메인 모델 도출

기획서, 유스케이스, 사용자 스토리와 같은 요구사항과 관련자와의 대화를 통해 도메인을 이해하고 이를 바탕으로 도메인 모델 초안을 만들어야 비로소 코드를 작성할 수 있다.

• 구현을 시작하려면 도메인에 대한 초기 모델이 필요하다.

도메인을 모델링할 때 기본이 되는 작업은 모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾는 것이다.

이 과정은 요구사항 에서 출발한다.

1. 요구사항은 어떤 데이터로 구성되는지 알려준다.
2. 요구사항은 관계를 알려준다.
3. 도메인을 구현하다 보면 특정 조건이나 상태에 따라 제약이나 규칙 이 달리 적용되는 경우가 많다.
4. 요구사항은 상태와 관련이 있다.

엔티티와 밸류

---

도출한 모델은 크게 엔티티(Entity) 와 밸류(Value)로 구분할 수 있다.

엔티티와 밸류를 제대로 구분해야 도메인을 올바르게 설계하고 구현할 수 있기 때문에 이 둘의 차이를 명확하게 이해하는 것이 도메인을 구현하는 데 있어 중요하다.

엔티티

엔티티의 가장 큰 특징은 식별자를 가진다.

식별자

• 엔티티 객체마다 고유해서 각 엔티티는 서로 다른 식별자를 갖는다.
• 엔티티를 생성하고 속성을 바꾸고 삭제할 때 까지 식별자는 유지된다.
• 두 엔티티 객체의 식별자가 같으면 두 엔티티는 같다고 판단할 수 있다.
• 엔티티를 구현한 클래스는 식별자를 이용해서 equals() 메서드와 hashCode() 메서드를 구현할 수 있다.

식별자

엔티티의 식별자를 생성하는 시점

• 도메인의 특징
• 사용하는 기술

에 따라 달라진다.

식별자는 다음 중 한 가지 방식으로 생성한다.

1. 특정 규칙에 따라 생성
   • 현재 시간과 다른 값을 함께 조합
2. UUID나 Nano ID와 같은 고유 식별자 생성기 사용
3. 값을 직접 입력
4. 일련번호 사용(시퀀스나 DB의 자동 증가 컬럼 사용)
   • 주로 데이터베이스가 제공하는 자동 증가 기능을 사용

밸류 타입

밸류 타입은 개념적으로 완전한 하나를 표현할 때 사용한다.

꼭 두 개 이상의 데이터를 가져야 하는 것은 아니다.

⇒ 의미를 명확하게 표현하기 위해 밸류 타입을 사용하는 경우도 있다.

// 예 : Money 타입
public class Money {
	private int value;

	public Money(int value) {
			this.value = value;
	}

	public int getValue() {
			return this.value;
	}
}

밸류타입의 또 다른 장점은 밸류 타입을 위한 기능을 추가할 수 있다는 것이다.

• Money 타입은 돈 계산을 위한 기능을 추가할 수 있다.

public class Money {
	private int value;

	public Money(int value) {
			this.value = value;
	}

	public int getValue() {
			return this.value;
	}

	public Money multiply(int multiplier) {
			return new Money(value * multiplier);
	}

}

밸류 타입은 코드의 의미를 더 잘 이해할 수 있도록 한다.(가독성 향상)

밸류 객체의 데이터를 변경할 때는 기존 데이터를 변경하기보다는 변경한 데이터를 갖는 새로운 밸류 객체를 생성하는 방식을 선호한다.

Money처럼 데이터 변경 기능을 제공하지 않는 타입을 불변 이라고 표현한다.

밸류 타입을 불변으로 구현하는 이유

• 안전한 코드를 작성할 수 있다.

두 밸류 객체를 비교할 때는 모든 속성이 같은지 비교한다.

set 메서드 넣지 않기

도메인 모델에 get / set 메서드 를 무조건 추가하는 것은 좋지 않은 버릇이다.

특히 set 메서드는 도메인의 핵심 개념이나 의도를 코드에서 사라지게 한다.

습관적으로 작성한 set 메서드는 필드값만 변경하고 끝나기 때문에 상태 변경과 관련된 도메인 지식이 코드에서 사라지게 된다.

• set 메서드의 또 다른 문제 : 도메인 객체를 생성할 때 온전하지 않은 상태가 될 수 있다.

⇒ 도메인 객체가 불완전한 상태로 사용되는 것을 막으려면 생성 시점에 필요한 것을 전달해 주어야 한다.

⇒ 즉, 생성자를 통해 필요한 데이터를 모두 받아야 한다.

불변 밸류 타입을 사용하면 자연스럽게 밸류 타입에는 set 메서드를 구현하지 않는다.

도메인 용어

---

도메인에서 사용하는 용어를 코드에 반영하지 않으면 그 코드는 개발자에게 코드의 의미를 해석해야 하는 부담을 준다.

⇒ 이는 코드의 가독성을 높여서 코드를 분석하고 이해하는 시간을 줄여준다.

• 최대한 도메인 용어를 사용해서 도메인 규칙을 코드로 작성하게 되므로 버그도 줄어든다.

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

도메인 용어에 알맞은 단어를 찾는 시간을 아까워 하지 말자!

출처

---

http://www.yes24.com/Product/Goods/108431347

도메인 주도 개발 시작하기 - YES24