Chapter1-도메인 모델 시작

도메인

• 온라인 서점(쇼핑몰) 소프트웨어는 온라인으로 책을 판매하는데 필요한 상품조회, 구매, 결제, 배송 추적 등의 기능을 제공해야 한다.
• 이때 ‘온라인 서점’은 소프트웨어로 해결하고자 하는 문제 영역, 즉 도메인에 해당한다.
• 한 도메인은 다시 하위 도메인으로 나눌 수 있다.

[그림1.1] 도메인은 여러 하위 도메인으로 구성된다.

• 카탈로그 하위 도메인은 고객에게 구매할 수 있는 상품 목록을 제공하고, 주문 하위 도메인은 고객의 주문을 처리한다.
  • 한 하위 도메인은 다른 하위 도메인과 연동하여 완전한 기능을 제공한다.
  • 예를 들어, 고객이 물건을 구매하면 주문, 결제, 배송, 혜택 하위 도메인의 기능이 엮이게 된다.

• 도메인마다 고정된 하위 도메인이 존재하는 것은 아니다.
  • 모든 온라인 쇼핑몰이 고객 혜택을 제공하는 것은 아니며 규모가 크지 않은 소규모 업체는 엑셀과 같은 도구를 이용해 수작업으로 정산을 처리할 수도 있다.
• 하위 도메인을 어떻게 구성하지 여부는 상황에 따라 달라진다.
  • 예를 들어 기업 고객을 대상으로 대형 장비를 판매하는 곳은 온라인으로 카탈로그를 제공하고 주문서를 받는 정도만 필요할 것이다.

도메인 모델

• 기본적으로 도메인 모델은 특정 도메인을 개념적으로 표현한 것이다.
• 예를 들어, 주문 도메인 모델을 살펴보자.

[그림1.3] 객체 기반 주문 도메인 모델

• [그림1.3]의 모델은 도메인의 모든 내용을 담고 있진 않지만 이 모델을 보면 주문(Order)은 주문번호(OrderNumber)와 지불할 총금액(totalAmounts)이 있고, 배송정보(Shipping)를 변경할 수 있음을 알 수 있다.
  • 즉, 도메인 모델을 사용하면 여러 관계자들이 동일한 모습으로 도메인을 이해하고 도메인 지식을 공유하는데 도움이 된다.
• 도메인을 이해하려면 도메인이 제공하는 기능과 도메인의 주요 데이터 구성을 파악해야 하는데, 이런 면에서 기능과 데이터를 함께 보여주는 객체 모델은 도메인을 모델링하기 적합하다.
• 도메인 모델을 객체로만 모델링할 수 있는 것은 아니고 상태 다이어그램 등 다양한 표현 방법을 사용할 수 있다.
  • 즉, 관계가 중요한 도메인이라면 그래프를 이용해서 도메인을 모델링할 수 도 있는 것처럼 적절하게 사용하는게 좋다.
• 도메인 모델은 기본적으로 도메인 자체를 이해하기 위한 개념 모델이다.
  • 개념 모델과 구현 모델은 서로 다르지만 구현 모델이 개념 모델을 최대한 따르도록 할 수는 있다.

하위 모데인과 모델: 모델의 각 구성 요소는 특정 도메인을 한정할 때 비로소 의미가 완전해지기 떄문에, 각 하위 도메인마다 별도로 모델을 만들어야 한다. 이는 카탈로그 하위 도메인 모델과 배송하위 도메인 모델을 따로 만들어야 한다는 것을 뜻한다.

도메인 모델 패턴

[그림1.5] 아키텍처 구성

• 일반적인 애플리케이션 아키텍처는 위 이미지와 같이 네 개의 층으로 구성된다.
• 각 계층의 역할은 다음과 같다.
  • 표현(UI) 계층: 사용자의 요청을 처리하고 사용자에게 정보를 보여준다. 여기서 사용자는 소프트웨어를 사용하는 사람 뿐 아니라 외부 시스템도 사용자가 될 수도 있다.
  • 응용(Application) 계층: 사용자가 요청한 기능을 실행한다. 업무 로직을 직접 구현하지 않으며 도메인 계층을 조합해서 기능을 실행한다.
  • 도메인 계층: 시스템이 제공할 도메인의 규칙을 구현한다.
  • 인프라스트럭처 계층: DB나 메시징 시스템과 같은 외뷔 시스템과의 연동을 처리한다.
• 도메인 계층은 도메인의 핵심 규칙을 구현한다.
  • 주문 도메인의 경우 ‘출고 전에 배송지를 변경할 수 있다’는 규칙과 ‘주문 취소는 배송 전에만 할 수 있다’는 규칙을 구현한 코드가 도메인 계층에 위치하게 된다.
  • 이런 도메인 규칙을 객체 지향 기법으로 구현하는 패턴이 도메인 모델 패턴이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class Order {
	private OrderState state;
	private ShippingInfo shippingInfo;

	public void changeShippingInfo(ShippingInfo newShippingInfo) {
		if (!state.isShippingChangeable()) {
			throw new IllegalStateException("can't change shipping in " + state);
		}
		this.shippingInfo = newShippingInfo;
	}

	public void changeShipped() {
		// 로직 검사
		this.state = OrderState.SHIPPED;
	}
	...
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public enum OrderState {
	PAYMENT_WAITING {
		public boolean isShippingChangeable() {
			return true;
		}
	},
	PREPARING {
		public boolean isShippingChangeable() {
			return true;
		}
	},
	SHIPPED, DELIVERING, DELIVERY_COMPLETED;

	public boolean isShippingChangeable() {
		return false;
	}
}

• 위 코드는 주문 도메인의 일부 기능을 도메인 모델 패턴으로 구현한 것이다.
  • 주문 상태를 표현하는 OrderState는 배송지를 변경할 수 있는지 여부를 검사할 수 있는 isShippingChangeable() 메서드를 제공하고 있다.
  • 코드를 보면 주문 대기 중(PAYMENT_WAITING) 상태와 상품 준비 중(PREPARING) 상태만 배송지를 변경할 수 있딴 것을 알 수 있다. 즉, OrderState는 주문 대기 중 이거나 상품 준비 중에는 배송지를 변경할 수 있따는 도메인 규칙을 구현하고 있다.
• 위 코드에선 배송지 변경 가능 여부를 판단할 규칙이 OrderState 쪽에 구현되어 있지만 Order 클래스에서 이를 구현할 수 도 있다.
  • 하지만어디에 있뜬 중요한 점은 주문과 관련된 중요 업무 규칙을 주문 도메인 모델인 Order나 OrderState에서 구현하다는 점이다.
• 핵심 규칙을 구현한 코드는 도메인 모델에만 위치하기 때문에 규칙이 바뀌거나 규칙을 확장해야 할 때 다른 코드에 영향을 덜 주고 변경 내역을 모델에 반영할 수 있게 된다.

Note: ‘도메인 모델’이란 용어는 도메인 자체를 표현하는 개념적인 모델을 의미하지만, 도메인 계층을 구현할 때 사용하는 객체 모델을 언급할 때에도 ‘도메인 모델’이란 용어를 사용한다.

개념 모델과 구현 모델: 처음부터 완벽한 개념 모델을 만들기보단 전반적인 개요를 알 수 있는 수준으로 개념 모델을 작성해야 한다. 프로젝트 초기에는 개요 수준의 개념 모델로 도메인에 대한 전체 윤곽을 이해하는데 집중하고, 구현하는 과정에서 개념 모델을 구현 모델로 점진적으로 발전시켜 나가야 한다.

도메인 모델 도출

• 기획서, 유스 케이스, 사용자 스토리와 같은 요구사항과 관련자와의 대화를 통해 도메인을 이해하고 이를 바탕으로 도메인 모델 초안을 만들어야 비로소 코드를 작성할 수 있다.
• 도메인을 모델링할 떄 기본이 되는 작업은 모델을 구성하는 핵심 구성요소, 규칙, 기능을 찾는 것이다.
• 주문 도메인과 관련된 몇가지 요구사항을 보자
  • 최소 한 종류 이상의 상품을 주문해야 한다.
  • 한 상품을 한 개 이상 주문할 수 있다.
  • 총 주문 금액은 각 상품의 구매 가격 합을 모두 더한 금액이다.
  • 각 상품의 구매 가격 합은 상품 가격에 구매 개수를 곱한 값이다.
  • 주문할 때 배송지 정보를 반드시 지정해야 한다.
  • 배송지 정보는 받는 사람 이름, 전화번호, 주소로 구성된다.
  • 출고를 하면 배송지 정보를 변경할 수 없다.
  • 출고 전에 주문을 취소할 수 있다.
  • 고객이 결제를 완료하기 전에는 상품을 준비하지 않는다.
• 위 요구사항을 통해 아직 상세 구현까지 할 수 있는 수준은 아니지만 Order에 관련 기능을 메서드로 추가할 수 있다.

1
2
3
4
5
6

public class Order {
	public void changeShipped() { ... }
	public void changeShippingInfo(ShippingInfo newShipping) { ... }
	public void cancel() { ... }
	public void completePayment() { ... }
}

• 다음 요구사항은 주문 항목이 어떤 데이터로 구성되는지 알려준다.
  • 한 상품을 한 개 이상 주문할 수 있다.
  • 각 상품의 구매 가격 합은 상품 가격에 구매 개수를 곱한 값이다.
• 두 요구사항에 따르면 주문 항목을 표현하는 OrderLine은 적어도 주문할 상품, 상품의 가격, 구매 개수를 포함하고 있어야 한다. 이를 OrderLine으로 구현하면 아래와 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class OrderLine {
	private Product product;
	private int price;
	private int quantity;
	private int amount;

	public OrderLine(Product product, int price, int quantity) {
		...
	}

	private int calculateAmounts() {
		return price * quantity;
	}

	public int getAmounts() { ... }
	...
}

• 다음 요구사항은 Order와 OrderLine과의 관계를 알려준다.
  • 최소 한 종류 이상의 상품을 주문해야 한다.
  • 총 주문 금액은 각 상품의 구매 가격 합을 모두 더한 금액이다.
• 한 종류 이상의 상품을 주문할 수 있으므로 Order는 최소 한 개이상의 OrderLine을 포함해야 한다.
• 또한, OrderLine으로부터 총 주문 금액을 구할 수 있다. 이를 코드에 반영하면 다음과 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public class Order {
	private List<OrderLine> orderLines;
	private int totalAmounts;

	public Order(list<OrderLine> orderLines) {
		setOrderLines(orderLines);
	}

	private void setOrderLines(List<OrderLine> orderLines) { 
			verityAtLeastOneOrMoreOrderLines(orderLines);
			this.orderLines = orderLines;
			calculateTotalAmounts();
	}

	private void verifyAtLeastOneOrMoeOrderLines(List<OrderLine> orderLines) { 
		if (orderLines == null || orderLines.isEmpty()) {
			throw new IllegalArgumentException("no OrderLine");
		}
	 }

	private void calculateTotalAmounts() { 
		this.totalAmounts == new Money(orderLines.stream()
			.mapToInt(x -> x.getAmounts().getValue()).sum());
	}

	...
}

• 요구사항에 따르면 최소 한 종류 이상의 상품을 주문해야 하므로 setOrderLines() 메서드는 verityAtLeastOneOrMoteOrderLines() 메서드를 이용하여 OrderLine이 한 개이상 존재하는지 검사한다.
  • 또한, calcuateTotalAmounts() 메서드를 이용해 총 주문 금액을 계산한다.
• 배송지 정보는 이름, 전화번호, 주소 데이터를 가지므로 ShippingInfo 클래스를 다음과 같이 정의하였다.

1
2
3
4
5
6
7
8
9

public class ShipingInfo {
	private String receiverName;
	private String receiverPhoneNumber;
	private String shipingAddress1;
	private String shipingAddress2;
	private String shipingZipcode;

	... 생성자, getter
}

• 앞서 요구사항 중에 ‘주문할 때 배송지 정보를 반드시 지정해야 한다’는 내용이 있는데 이는 Order 생성시 생성자에 OrderLine의 목록 뿐만 아니라 ShippingInfo도 함께 전달해야 함을 의미한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class Order {
    private List<OrderLine> orderLines;
    private ShippingInfo shippingInfo;
    ...

    public Order(List<OrderLine> orderLines, ShippingInfo shippingInfo) {
        setOrderLines(orderLines);
        setShippingInfo(shippingInfo);
    }

    private void setShippingInfo(ShippingInfo shippingInfo) {
    	if(shippingInfo == null) {
    	    throw new IllegalArgumentException("no ShippingInfo");
    	}
    	this.shippingInfo = shippingInfo;
    }
    ...
}

• 생성자에서 호출하는 setShippingInfo() 메서드는 ShippingInfo가 null이면 Exception을 발생하는데, 이렇게 함으로써 배송지 정보 필수라는 도메인 규칙을 구현한다.
• 도메인을 구현하다 보면 특정 조건이나 상태에 따라 제약이나 규칙이 달리 적용되는 경우가 많다.
  • 출고를 하면 배송지 정보를 변경할 수 없다.
  • 출고 전에 주문을 취소할 수 있다.
  • 고객이 결제를 완료하기 전에는 상품을 준비하지 않는다.
• 이는 요구사항이 추가로 존재할 수 있는 상태를 분석한 뒤, 다음과 같이 열거 타입을 이용해서 상태 정보를 표현할 수 있다.

1
2
3
4
5
6
7
8

public enum OrderState {
	PAYMENT_WAITING, 
	PREPARING, 
	SHIPPED, 
	DELIVERING, 
	DELIVERY_COMPLETED, 
	CANCELED 
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class Order{
	private OrderState state;
	
	public void changeShippingInfo(ShippingInfo newShippingInfo) {
		verifyNotYetShipped();
		setShippingInfo(newShippingInfo);
	}
	public void cancel(){
		verifyNotYetShipped();
		this.state = OrderState.CANCELED;
	}
	private void verifyNotYetShipped(){
		if(state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING)
			throw new IllegalStateException("already shippped");
	}
	...
}

문서화: 문서화를 하는 주된 이유는 지식을 공유하기 위함이다. 코드를 이용해 전체 소프트웨어를 분석하려면 많은 시간이 소요되지만 전반적인 기능 목록이나 모듈 구조, 빌드 과정은 코드를 보고 직접 이해하는 것보다 상위 수준에서 정리한 문서를 참조하는 것이 소프트웨어 전반을 빨르게 이해하는데 도움이 된다. 그리고 코드가 도메인을 잘 표현해야 비로소 코드의 가독성이 높아지며 문서로서 코드가 의미를 갖는다.

엔티티와 벨류

엔티티

• 엔티티는 식별자를 갖는다.
  • ex) 주문 도메인 -> 식별자: ‘주문 번호’
  • Order는 엔티티로서 orderNumber를 식별자로 갖는다.
• 엔티티의 식별자는 바뀌지 않고 고유하기 떄문에 두 엔티티 객체의 식별자가 가틍면 두 엔티티를 같다고 판단할 수 있따.
• 엔티티를 구현한 클래스는 다음과 같이 식별자를 이용해서 equals() 메서드와 hashcode() 메서드를 구현할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class Order {
	public String orderNumber;
	
	@Override
	public boolean equals(Object obj){
		if (this == obj) return true;
		if (obj == null) return false;
		if (obj.getClass() != Order.class) return false;
		Order other = (Order)obj;
		if (this.orderNumber == null) return false;
		return this.orderNumber.equals(other.orderNumber);
	}

	@Override
	public int hashCode(){
		final int prime = 31;
		int result = 1;
		result = prime * result + ((orderNumber == null) ? 0 : orderNumber.hashCode());
		return result;
	}
}

엔티티의 식별자 생성 방식

• 1)특정 규칙에 따라 생성한다 - 주문번호,운송장번호 등 특정 규칙에 따라 생성
• 2)UUID 사용
  • UUID uuid = UUID.randomUUID();
  • // 615fsdf34-c342-5scd-d33d-123145sadfa 와 같은 문자열
• 3)값을 직접 입력 - 회원 아이디, 이메일
• 4)일렬번호 사용 (시퀀스나 DB의 자동 증가 칼럼(auto_increment) 사용)

벨류 타입

1
2
3
4
5
6
7
8
9
10

public class ShippingInfo {
	private String receiverName;  // 받는 사람
	private String receiverPhoneNumber; // 받는 사람

	private String shippingAddress1; // 주소
	private String shippingAddress2; // 주소
	private String shippingAddressZipcode; // 주소

	...
}

• ShippingInfo 클래스의 receiverName 필드와 receiverPhoneNumber 필드는 서로 다른 두 데이터를 담고 있지만 두 필드는 개념적으로 받는 사람을 의미한다.
  • 즉, 두 필드는 실제로 한 개의 개념을 표현하고 있다.
• 비슷하게 shippingAddress1, shippingAddress2, shippingAddressZipcode 는 주소라는 하나의 개념을 표현한다.
• 벨류 타입은 개념적으로 완전한 하나를 표현할 떄 사용한다.
• 예를 들어, 받는 사람을 위한 벨류 타입인 Receiver와 주소 관련 데이터를 표현하는 Address 를 다음과 같은 벨류 타입으로 작성할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

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

	public String getName(){
		return name;
	}
	public String getPhoneNumber(){
		return phoneNumber;
	}
}

1
2
3
4
5
6
7

public class Address{
	private String address1;
	private String address2;
	private String zipcode;
	
	...
}

• 벨류 타입을 이용한 ShippingInfo 클래스는 다음과 같이 변경될 것이다.

1
2
3
4
5
6

public class ShippingInfo{
	private Receiver receiver;
	private Address address;
	
	...
}

• 벨류 타입이 꼭 두 개 이상의 데이터를 가져야 하는 것은 아니다.
• 의미를 명확히 표현하기 위해 사용하는 경우도 있다.
• 이를 위한 좋은 예가 OrderLine이다.

1
2
3
4
5
6
7

public class OrderLine {
	private Product product;
	private int price;
	private int quantity;
	private int amounts;
...
}

• price와 amounts는 int 타입의 숫자를 사용하고 있지만, 의미하는 값은 ‘돈’ 이다.
• 따라서 ‘돈’을 의미하는 Money 타입을 만들어 사용하면 코드를 이해하는데 도움 된다.

1
2
3
4
5
6
7
8
9
10
11

public class Money{
	private int value;

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

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

1
2
3
4
5
6
7

public class OrderLine{
	private Product product;
	private Money price; // Money 타입 덕에 price가 금액을 의미한다는 것을 쉽게 유추할 수 있음
	private int quantity;
	private Money amounts; // Money 타입 덕에 price가 금액을 의미한다는 것을 쉽게 유추할 수 있음
...
}

• 벨류 타입을 사용할 때의 또 다른 장점은 벨류 타입을 위한 기능을 추가할 수 있다는 것이다.
  • 예를 들어, Money 타입은 다음과 같이 돈 계산을 위한 기능을 추가할 수 있다.
  • 또한 이를 통해 벨류 타입은 코드의 의미를 더 잘 이해할 수 있도록 한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

public class Money{
	private int value;

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

	public int getValue() {
		return this.value;
	}
	
	//새로운 기능 추가 가능
	public Money add(Money money){
		return new Money(this.value + money.value);
	}
	public Money multiply(int multiplier) {
		return new Money(this.value * multiplier);
	}
}

참조 투명성과 관련된 문제

• 벨류 객체의 데이터 변경시 기존 데이터를 변경하기보단 변경한 데이터를 갖는 새로운 객체를 생성하는 방식이 좋다.
  • 예를 들어, 앞서 Money 클래스의 add 메서드를 보면 Money를 새로 생성하고 있다.
• Money처럼 데이터 변경 기능을 제공하지 않는 타입을 불변(immutable)이라 표현한다.
• 벨류 타입을 불변으로 구현하는 이유는 여러가지가 있는데 가장 중요한 이유는 보다 안전한 코드를 작성할 수 있다는 것이다.
• 만약 Money 가 setValue와 같은 메서드를 제공하여 값을 변경할 수 있다면 아래 이미지처럼 OrderLine의 price값이 잘못 반영되는 상황이 발생하게 된다.

1
2
3

Money price = new Money(1000);
OrderLine line = new OrderLine(product, price, 2) // -> [price=1000, quantity=2, amounts=2000]
price.setValue(2000); // -> [price=2000, quantity=2, amounts=2000]

• 이런 문제를 방지하려면 OrderLine 생성자는 다음과 같이 새로운 Money 객체를 생성하도록 코드를 작성해야 한다.
  • 하지만, Money가 불변이라면 이런 코드를 작성할 필요가 없다.
  • 그렇지만 개인적인 생각은 추후 어떠한 변경사항이 생길지 모르기 떄문에 안전하게 아래와 같이 처리하는게 좋은것 같다,.

1
2
3
4
5
6
7
8
9
10
11
12

public class OrderLine {
	...
	private Money price;

	public OrderLine(Product product, Money price, int quantity) {
		this.product = product;
		// Money 가 불변 객체가 아니라면,
		// price 파라미터가 변경될 떄 발생하는 문제를 방지하기 위해
		// 데이터를 복사한 새로운 객체를 생성해야 한다.
		this.price = new Money(price.getValue());
	}
}

• 두 벨류 객체가 같은지 비교할 땐 모든 속성이 같은지 비교해야 한다.

1
2
3
4
5
6
7
8
9
10
11
12
13

public class Receiver{
	private String name;
	private String phoneNumber;
	
	public boolean equals(Object other){
		if (other == null) return false;
		if (this == other) return true;
		if (! (other instanceof Receiver)) return false;
		Receiver that = (Receiver) other;
		
		return this.name.equals(that.name) && this.phoneNumber.equals(that.phoneNumber);
	}
}

엔티티 식별자와 벨류 타입

• 식별자가 어떤 도메인의 식별자인지를 분명히 나타내기 위해서 밸류 타입을 사용할 수 있다.
  • 밸류 타입을 통해 식별자의 의미를 분명히 드러낼 수 있다.

1
2
3
4
5

public class Order{
	//private String id;
	private OrderNo id;
	...
}

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

• 도메인 모델에 get/set 메서드를 무조건 추가하는것은 좋지 않은 버릇이다.
• set메서드는 도메인의 핵심 개념이나 의도를 코드에서 사라지게 한다.
  • 앞서 changeShippingInfo()가 배송지 정보를 새로 변경하다는 의미를 가졌다면 setShippingInfo() 메서드는 단순히 배송지 값을 설정한다는 것을 뜻한다.
  • completePayment()는 결제 완료와 관련된 처리 코드를 함께 구현하기 때문에 결제 완료와 관련된 도메인 지식을 코드로 구현하는 것이 자연스럽다.
  • 하지만 setOrderState는 단순히 상태값만 변경할지 아니면 상태 값에 따라 다른 처리를 위한 코드를 함꼐 구현할지 애매하다.
• set 메서드의 또 다른 문제점은 도메인 객체를 생성시 완전한 상태가 아닐 수도 있다는 것이다.

1
2
3
4
5
6
7
8
9
10

// set 메서드로 데이터를 전달하도록 구현하면
// 처음 Order를 생성하는 시점에 order는 완전하지 않다.
Order order = new  Order();

// set 메서드로 필요한 모든 값을 전달해야 한다. 
order.setOrderLine(lines);
order.setShippingInfo(shipingInfo);

// 주문자(Orderer)를 설정하지 않은 상태에서 주문 완료 처리 -> 문제 발생!!!
order.setState(OrderState.PREPARING);

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

1

Order order = new Order(orderer, lines, shippingInfo, OrderState.PREPARING);

• 생성자로 필요한 것을 모두 받으므로 다음처럼 생성자를 호출하는 시점에 필요한 데이터가 올바른지 검사할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

public class Order {
    public Order(Orderer orderer, List<OrderLine> orderLines, ShippingInfo shippingInfo, OrderState orderState) {
		setOrderer(orderer);
		setOrderLines(orderLines);
		... // 다른 값 설정
	}

	private void setOrderer(Orderer orderer) {
		if (orderer == null) {
			throw new IllegalArgumentException("no orderer");
		}
		this.orderer = this.orderer;
	}

	private void setOrderLines(List<OrderLine> orderLines) {
		vverifyAtLeastOneOrMoeOrderLines(orderLines);
		this.orderLines = orderLines;
		calculateTotalAmounts();
	}

	private void verifyAtLeastOneOrMoeOrderLines(List<OrderLine> orderLines) { 
		if (orderLines == null || orderLines.isEmpty()) {
			throw new IllegalArgumentException("no OrderLine");
		}
	 }

	private void calculateTotalAmounts() { 
		this.totalAmounts == new Money(orderLines.stream()
			.mapToInt(x -> x.getAmounts().getValue()).sum());
	}
}

• 이 코드의 set 메서드는 접근 범위가 private 이다.
  • 즉, 클래스 내부에서ㅔ 데이터를 변경할 목적으로 사용되며 외부에선 데이터를 호출할 수 없다.
• 불변 밸류 타입을 사용하면 자연스럽게 밸류 타입엔 set 메서드를 구현하지 않도록 하여 불변 타입의 장점을 살리도록 한다.

DTO의 get/set 메서드: DTO가 도메인 로직을 담고 있지는 않기에 get/set 메서드를 제공해도 도메인 객체의 데이터 일관성에 영향을 줄 가능성이 높지 않다.

도메인 용어

• 코드를 작성할 때 도메인에서 사용하는 용어는 매우 중요하다. 도메인에서 사용하는 용어를 코드에 반영하지 않으면 그 코드는 개발자에게 코드의 의미를 해석해야 하는 부담을 준다.

1
2
3

public OrderState {
	STEP1, STEP2, STEP3, STEP4, STEP5, STEP6
}

1
2
3
4
5
6
7

public class Order {
	public void changeShippingInfo(ShippingInfo shippingInfo) {
		verifySetp1OrStep2();
		...
	}
	public void verityStep1OrStep2() { ... }
}

• 기획자나 온라인 쇼핑 도메인 전문가가 개발자와의 업무 회의에서 ‘출고 전’이라는 단어를 사용하면 개발자는 머릿속으로 ‘출고 전은 STEP1과 STEP2’라고 도메인 지식을 코드로 해석해야 한다.
• 도메인 용어는 좋은 코드를 만드는 데 매우 중요하지만 국내 개발자에게 불리한 면이 있다. 바로 영어 때문이다.
  • 분야의 특성상 알파벡과 숫자를 사용해서 클래스, 필드, 메서드 등의 이름을 작성하게 되는데 이는 도메인 용어를 영어로 해석하는 노력이 필요함을 뜻한다.
• 알맞은 영어 단어를 찾는 것은 쉽지 않은 일이지만 시간을 들여 찾는 노력을 해야 한다. 적절한 단어를 사용하려는 노력하지 않는다면 코드는 도메인과 점점 멀어지게 된다.

Chapter2-아키텍처 개요

네 개의 영역

표현 영역

• 표현 영역(UI영역)은 사용자의 요청을 받아 응용 영역에 전달하고 응용 영역의 처리 결과를 다시 사용자에게 보여주는 역할을 한다.
  • 표현 영역의 사용자는 웹 브라우저를 사용하는 사람일 수 도 있고, REST API 를 호출하는 외부 시스템일 수도 있다.
• 표현 영역을 통해 사용자의 요청을 전달받는 응용 영역은 시스템이 사용자에게 제공해야 할 기능을 제공한다.
  • 예를 들어, ‘주문 등록’, ‘주문 취소’, ‘상품 상세조회’ 와 같은 기능을 구현한다.

응용 영역

• 응용 영역은 기능을 구현하기 위해 도메인 영역의 도메인 도메인 모델을 사용한다.
• 응용 서비스는 로직을 직접 수행하기보단 도메인 모델에 로직 수행을 위임한다. 마치 아래 예제 코드처럼 Order 도메인 모델에 취소 처리를 위임하는 것처럼.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@Service
public class CancelOrderService {
    ...

    @Transactional
    public void cancel(String orderId) {
        Order order = findOrderById(orderId);
        if (order == null) {
            throw new OrderNotFoundException(orderId);
        }
        order.cancel();
    }

	...
}

도메인 영역

• 도메인 영역은 도메인 모델을 구현한다.
  • 도메인 모델은 도메인의 핵심 로직을 구현한다. (ex. 주문 도메인의 배송지 변경, 결제 완료, 주문 총액 계산과 같은)

인프라스트럭처 영역

• 구현 기술에 대한 것을 다룬다.
• 예를 들어, RDBMS, MessageQueue, 몽고 DB, HBase 와의 연동을 처리한다.
• 추가적으로 SMTP를 이용한 메일 발송 기능을 구현하거나 HTTP 클라이언트를 이용해서 REST API 를 호출하는 것도 처리한다.

도메인, 응용, 표현 영역은 실제 구현 기술을 사용한 코드를 직접 만들지 않는다. 대신 인프라스트럭처 영역에서 제공하는 기능을 ㅅ용해서 필요한 기능을 개발한다. 예를 들어, 응용 영역에서 DB에 보관된 데이터가 필요하면 인프라스트럭처 영역의 DB 모듈을 사용해서 데이터를 읽어온다. 비슷하게 외부에 메일을 발송하려면 인프라스트럭처가 제공하는 SMTP 연동 모듈을 이용해 메일을 발송한다.

계층 구조 아키텍처

• 네 영역을 구성할 때 많이 사용하는 아키텍처가 [그림2.4]와 같은 계층 구조이다.
  • 도메인의 복잡도에 따라 응용과 도메인을 분리하기도 하고 합치기도 한다.

• 계층 구조는 단방향(하위 계층)으로만 의존하게 한다.
• 계층 구조를 엄격하게 적용하면 상위 계층은 바로 아래 계층에만 의존을 가져야 하지만, 구현의 편리함을 위해 계층 구조를 유옇나게 적용한다.
  • 예를 들어, 응용 계층에서 외부 시스템과의 연동을 위해 더 아래 계층인 인프라 계층에 의존하기도 한다.
• 계층 구조에 따르면 도메인과 응용 계층은 룰 엔진과 DB 연동을 위해 아래 이밎와 같이 인프라 모듈에 의존하게 된다.

• 여기서 짚고 넘어가야 할 것은 표현, 응용, 도메인 계층이 상세한 구현 기술을 다루는 인프라 계층에 종속된다는 점이다.
• 이때 문제가 생길 수 있는 부분이 있다.
• 도메인의 가격 계산 규칙을 정할 때 할인 금액 계산 로직이 복잡해지면 객체 지향으로 로직을 구현하는 것 보단 룰 엔진을 사용하는 것이 더 알맞을 때가 있다.
• Drools라는 룰 엔진을 사용해서 로직을 수행할 수 있는 인프라 스트럭처 코드이다. (Drools는 무시해도 된다.)
• 핵심은 evalute() 메서드에 값을 주면 별도 파일로 작성한 규칙을 이용해서 연산을 수행하는 코드라는 것 정도로만 이해하면 된다.

1
2
3
4
5
6
7

// 인프라스트럭처 영역
public class DroolsRuleEngine {
 ...
 public void evalute(String sessionName, List<?> facts) {
  ...
 }
}

응용 영역은 가격 계산을 위해 인프라스트럭처 영역의 DroolsRuleEngine을 사용한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

// 응용 영역
public class CalculateDiscountService {
 
 private DroolsRuleEngine ruleEngine;

 public CalculateDiscountService() {
	ruleEngine = new DroolsRuleEngine();
 }

 public Money calculateDiscount(OrderLine orderLines, String customerId) {
  Customer customer = findCusotmer(customerId);

  MutableMoney money = new MutableMoney(0);
  List<?> facts = Arrays.asList(customer, money);
  facts.addAll(orderLines);
  ruleEngine.evalute("discountCalculation", facts);
  return money.toImmutableMoney();
 }
 ...
}

• 위 응용 영역에 위치한 서비스 코드는 두 가지 문제가 존재한다.
  • 1)CalculateDiscountService 만 테스트하기 어렵다. RuleEnigne이 완벽하게 동작해야만 하며 이에 대한 설정 파일도 필요하게 된다.
  • 2)구현 방식을 변경하기 어렵다는 점이다. discountCalculation 문자열은 Drools의 세션 이름이다. Drools의 세션 이름을 변경시 CalculateDiscountService의 코드도 같이 변경되어야한다.
• 이처럼 인프라스트럭처 계층에 의존하면 테스트의 어려움과 기능 확장의 어려움 이라는 두 가지 문제가 생긴다. 이를 해결하기 위해 SOLID 원칙 중 하나인 DIP 를 적용하면 된다.

DIP

• 가격 할인 계산을 하려면 아래 이미지의 왼쪽과 같이 고객 정보를 구해야 하고, 구현할 고객 정보와 주문 정보를 이용해서 룰을 실행해야 한다.

• 위 이미지에서 CalculateDicountService 는 고수준 모듈이다.
• 고수준 모듈이란 의미 있는 단일 기능을 제공하는 모듈이다.
• CalculateDicountService는 ‘가격 할인 계산’ 이라는 기능을 구현한다.
• 고수준 모듈의 기능을 구현하려면 여러 하위 기능이 필요하다.
• 가격 할인 계산 기능을 구현하려면 고객 정보를 구해야 하고 룰을 실힝해야 하는데 이 두 기능이 하위 기능이다.
• 저수준 모듈은 하위 기능을 실제로 구현한 것이다.

• [그림 2.7] 에서 JPA를 이용해서 고객 정보를 읽어오는 모듈과 Drools로 룰을 실행하는 모듈이 저수준 모듈이다.

• 고수준 모듈이 제대로 동작하려면 저수준 모듈을 사용해야 한다. 그런데, 고수준 모듈이 저수준 모듈을 사용하면 앞서 계층 구조 아키텍처에서 언급했던 두 가지 문제(구현 변경과 테스트가 어려움)가 발생한다.
• DIP 는 이 문제를 해결하기 위해 저수준 모듈이 고수준 모듈에 의존하도록 바꾼다.
  • 이렇게 하기 위해서 추상화한 인터페이스가 필요하게 된다.
• CalculateDiscountService 입장에서 봤을 땐 룰 적용을 Drools 로 구현했는지, 자바로 직접 구현했는지 중요치 않다.
  • 단지, ‘고객 정보와 구매 정보에 룰을 적용해서 할인 금액을 구한다’ 는 것이 중요할 뿐이다.
• 이를 추상화한 인터페이스는 다음과 같다.

1
2
3

public interface RuleDiscounter {
  publis Money applyRules(Customer customer, List<OrderLine> orderLines);
}

이제 CalCulateDiscountService 가 RuleDiscounter 를 이용하도록 바꿔보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class CalculateDiscountService {
 private RuleDiscounter ruleDiscounter;
 private CustomerRepository customerRepository;

 public CalculateDiscountService(RuleDiscounter ruleDiscounter, CustomerRepository customerRepository) {
  this.ruleDiscounter = ruleDiscounter;
  this.customerRepository = customerRepository
 }

 public Money calculateDiscount(OrderLine orderLines, String customerId) {
  Customer customer = customerRepository.findCusotmer(customerId);
  return ruleDiscounter.applyRules(customer, orderLines);
 }

 private Customer findCustomer(String customerId) {
  Customer customer = customerRepository.findById(customerId);
  if (customer == null) throw new NoCustomerException();
  return customer;
 }
 ...
}

• CalculateDiscountService 는 Drools 에 의존하는 코드를 포함하고 있지 않다.
  • 단지 RuleDiscounter가 룰을 적용한다는 것만 알 뿐이다.
• 룰 적용을 구현한 클래스는 RuleDiscounter 인터페이스를 상속받아 구현하다.

1
2
3
4
5
6
7
8
9

public class DroolsRuleDiscounter implements RuleDiscounter {
  ...

  @Override
  public Money applyRule(Customer customer, List<OrderLine> orderLines) {
    // 실제 구현 코드 생략
    return money;
  }
}

• 아래 이미지는 RuleDiscounter가 출현하면서 바뀐 구조를 보여주고 있다.

• 위 이미지 [그림 2.8]의 구조를 보면 CalculateDiscountService는 더 이상 구현 기술인 Drools에 의존하지 않는다.
• ‘룰을 이용한 할인 금액 계산’을 추상화한 RuleDiscounter 인터페이스에 의존할 뿐이다.
• ‘룰을 이용한 할인 금액 계산’은 고수준 모듈의 개념이므로 RuleDiscounter 인터페이스는 고수준 모듈에 속한다.
• DroolsRuleDiscounter는 고수준의 하위 기능인 RuleDiscounter를 구현한 것이므로 저수준 모듈에 속한다.

• DIP를 적용하면 위 이미지와 같이 저수준 모듈이 고수준 모듈에 의존하게 된다.
  • 고수준 모듈이 저수준 모듈을 사용하려면 고수준 모듈이 저수준 모듈에 의존해야 하는데, 반대로 저수준 모듈이 고수준 모듈에 의존한다고 해서 이를 DIP(Dependency Inversion Principle, 의존 역전 원칙) 라고 부른다.
• 이처럼 DIP를 적용하면 앞서 다른 영역이 인프라스트럭처 영역에 의존할 때 발생했떤 두 가지 문제인 구현 교체가 어렵다는 문제와 테스트가 어려운 문제를 해소할 수 있다.

1) 구현체 교체의 어려움 해결

• 고수준 모듈은 더 이상 저수준 모듈에 의존하지 않고 구현을 추상화한 인터페이스에 의존한다.
• 실제 사용할 저수준 구현 객체는 아래 코드처럼 의존 주입을 이용해 전달받을 수 있다.

1
2
3
4
5

// 사용할 저수준 객체 생성
RuleDiscounter ruleDiscounter = new DroolsRuleDiscounter();

// 생성자 방식으로 주입
CalculateDiscountService calculateDiscountService = new CalculateDiscountService(ruleDiscounter);

• 만약 구현 기술을 변경하더라도 CalculateDicountService를 수정할 필요가 없다.
• 아래 코드처럼 사용할 저수준 구현 객체를 생성하는 부분의 코드만 변경하면 되기 때문이다.

1
2
3
4
5

// 사용할 저수준 구현 객체 변경
RuleDiscounter ruleDiscounter = new SimpleRuleDiscounter();

// 사용할 저수준 모듈을 변경해도 고수준 모듈을 수정할 필요가 없다.
CalculateDiscountService calculateDiscountService = new CalculateDiscountService(ruleDiscounter);

• 의존 주입을 지원하는 스프링과 같은 프레임워크를 사용하면 설정 코드를 수정해서 쉽게 구현체를 변경할 수 있다.

1) 테스트 어려움 해결

• CalculateDiscountService가 제대로 동작하는지 테스트하려면 CustomerRepository와 RuleDiscounter를 구현한 객체가 필요하다.
• 하지만 둘 다 인터페이스로 추상화 했기 때문에 대용 객체를 사용해서 테스트를 진행할 수 있다.
• 다음은 대용 객체를 사용해서 Customer가 존재하지 않는 경우 익셉션이 발생하는지 검증하는 테스트 코드인데, 실제 구현 클래스 없이 테스트 가능함을 보여준다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class CalculateDiscountServiceTest {

  @Test(expected = NoCustomerException.class);
  public void noCustomer_thenExceptionShouldBeThrown() {
    // 테스트 목적의 대용 객체
    CustomerRepository stubRepo = mock(CustomerRepository.class);
    when(stubRepo.findById("noCustId")).thenReturn(null);

    RuleDiscounter stubRule = (cust, lines) -> null;

    // 대용 객체를 주입받아 테스트 진행
    CalculateDiscountService calcDisSvc = new CalculateDiscountService(stubRepo, stubRule);
    calcDisSvc.calculateDiscount(someLines, "noCustId");
  }
}

• 이렇게 실제 구현 없이 테스트 할 수 있는 이유는 DIP를 적용해서 고수준 모듈이이 저수준 모듈에 의존하지 않도록 했기 때문이다.
  • 고수준 모듈인 CalculateDiscountService는 저수준 모듈에 직접 의존하지 않기 때문에 실제 저수준 구현 클래스 없이도 테스트 대용 객체를 이용해서 거의 모든 기능을 테스트할 수 있는 것이다.

DIP 주의사항

• DIP의 핵심은 고수준 모듈이 저수준 모듈에 의존하지 않도록 하기 위함이다.
• 하지만 아래 이미지와 같이 저수준 모듈에서 인터페이스를 추출하는 경우가 있다.

• 위 이미지는 잘못된 구조이다.
• 이 구조에서 도메인 영역은 이프라 스트러거 영역에 의존하고 있다.
  • 즉, 여전히 고수준 모듈이 저수준 모듈에 의존하고 있는 것이다.
• RuleEngine 인터페이스는 고수준 모듈인 도메인 관점이 아니라 룰 엔진이라는 저수준 모듈 관점에서 도출한 것이다.
• DIP를 적용할 때 하위 기능을 추상화한 인터페이스는 고수준 모듈 관점(도메인 영역)에서 도출한다.
  • CalculateDiscountService 입장에서 봤을 때 할인 금액을 구하기 위해 룰 엔진을 사용하는지, 직접 연산하는지 여부는 중요치 않다.
  • 단지 규칙에 따라 할인 금액을 계산한다는 것이 중요할 뿐이다.
  • 즉, ‘할인 금액 계산’을 추상화한 인터페이스는 저수준 모듈이 아닌 고수준 모듈에 위치한다.(아래 이미지 참고)

DIP와 아키텍처

• 인프라스트럭처 영역은 구현 기술을 다루는 저수준 모듈이고 응용 영여과 도메인 영역은 고수준 모듈이다.
• 인프라스트럭처 계층의 가장 하단에 위치하는 계층형 구조와 달리 아키텍처에 DIP를 적용하면 [그림 2.12]와 같이 인프라스트럭처 영역이 응용 영역과 도메인 영역에 의존(상속)하는 구조가 된다.

• 인프라스트럭처에 위치한 클래스가 도메인이나 응용 영역에 정의한 인터페이스를 상속받아 구현하는 구조가 되므로 도메인과 응용 영역에 대한 영향을 주지 않거나 최소화하면서 구현 기술을 변경하는 것이 가능하다.

• 위 이미지에서 인프라스트럭처 영역의 EmailNotifier 클래스는 응용 영역의 Notifier 인터페이스를 상속 받고 있다.
  • 주문 시 통지 방식에 SMS를 추가해야 한다는 요구사항이 들어왔을땐 응용 영역의 OrderService를 변경할 필요가 없다.
  • [그림 2.14]와 같이 두 통지 방식을 함께 제공하는 Notifier 구현 클래스를 인프라 스트럭처 영역에 추가하면 된다.
  • 비슷하게 MyBatis 대신 JPA를 구현 기술로 사용하고 싶다면 JPA를 이용한 OrderRepository 구현 클래스를 인프라스트럭처 영역에 추가하면 된다.

도메인 영역의 주요 구성요소

• 엔티티:
  • 고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 가진다.
  • 주문(Order), 회원(Member), 상품(Product)과 같이 도메인의 고유한 개념을 표현한다.
  • 도메인 모델의 데이터를 포함하며 해당 데이터와 관련된 기능을 함께 제공한다.
• 밸류:
  • 고유의 식별자를 갖지 않는 개체로 주로 개념적으로 하나인 도메인 객체의 속성을 표현할 때 사용된다.
  • 주소(Address), 금액(Money)와 같은 타입이 밸류 타입이다.
  • 엔티티의 속성으로 사용될 뿐 아니라 다른 밸류 타입의 속성으로도 사용될 수 있다.
• 애그리거트(Aggregate):
  • 관련된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다.
  • 예를 들어, 주문과 관련된 Order 엔티티, OrderLine 밸류, Orderer 밸류 객체를 ‘주문’ 애그리거트로 묶을 수 있다.
• 리포지토리(Repository):
  • 도메인 모델의 영속성을 처리한다.
• 도메인 서비스(Domain Service):
  • 특정 엥ㄴ티티에 속하지 않은 도메인 로직을 제공한다.
  • ‘할인 금액 계산’은 상품, 쿠폰, 회원 등급, 구매 금액 등 다양한 조건을 이용해서 구현하게 되는데, 이렇게 도메인 로직이 여러 엔티티와 밸류를 필요로 할 경우 도메인 서비스에서 로직을 구현한다.

엔티티와 밸류

• 실제 도메인 모델의 엔티티와 DB 관계형 모델의 엔티티는 같은 것이라 볼 수 없다.
• 위 두 모델의 가장 큰 차이점은 도메인 모델의 엔티티는 데이터와 도메인 기능을 함께 제공한다는 점이다.

1
2
3
4
5
6
7
8
9
10
11

public class Order {
  // 주문 도메인 모델의 데이터
  private OrderNo number;
  private Orderer orderer;
  private ShippingInfo shippingInfo;

  // 도메인 모델 엔티티는 모데인 기능도 함께 제공
  public void changeShippingInfo(ShippingInfo newShippingInfo) {
    ...
  }
}

• 또 다른 차이점은 모데인 모델의 엔티티는 두 개 이상의 데이터가 개념적으로 하나인 경우 밸류 타입을 이용해서 표현할 수 있다는 것ㅇ이다.
• 위 코드에서 주문자를 푠현하는 Orderer 는 밸류 타입으로 다음과 같이 주문자이름과 이메일 데이터를 포함할 수 있다.

1
2
3
4
5

public class Orderer {
  private String name;
  private String email;
  ...
}

• 이를 DB 테이블로 표현하려면 아래 이미지와 같이 두 가지 방식을 적용할 수 있다.

• 왼쪽 테이블의 경우 주문자(Orderer)라는 개념이 드러나지 않고 주문자의 개별 데이터만 드러난다.
• 오른쪽 테이블의 경우 주문자 데이터를 별도 테이블에 저장했찌만 이는 테이블의 엔티티에 가깝지 밸류 타입의 의미가 드러나진 않는다.
• 반면 도메인 모델의 Orderer 는 주문자라는 개념을 잘 반영하므로 도메인을 보다 잘 이해할 수 있도록 돕는다.
• 그리고 앞서 설명했던 것처럼 밸류는 불변으로 구현하는 것을 권장한다.
  • 이는 엔티티의 밸류 타입 데이터를 변경시 객체 자체를 완전히 새로 교체한다는 것을 의미한다.

Chapter3-애그리거트

애그리거트

애그리거트의 필요성

• 도메인이 커질수록 개발할 도메인 모델도 커지면서 많은 엔티티와 밸류가 출현한다.
• 엔티티와 밸류 개수가 많아지면 많아질수록 모델은 점점 더 복잡해진다.
• 도메인 모델이 복잡해지면 개발자가 전체 구조가 아닌 한 개 엔티티와 밸류에만 집중하게 되는 경우가 발생한다.
• 이떄 상위 수준에서 모델을 관리하기보다 개별 요소에만 초점을 맞추다 보면 큰 수준에서 모델을 이해하지 못해 큰 틀에서 모델을 관리할 수 없는 상항에 빠질 수 있다.
• 도메인 모델도 개별 객체뿐만 아니라 상위 수준에서 모델을 볼 수 있어야 전체 모델의 관계와 개별 모델을 이해하는데 도움이 된다.
• 도메인 모델에서 전체 구조를 이해하는데 도움이 되는 것이 바로 애그리거트(Aggregate) 이다.

애그리거트의 정의

• 애그리거트는 관련 객체를 하나로 묶은 군집이다.
• 대표적인 예가 주문이다.
  • 주문이라는 도메인 개념은 ‘주문’, ‘배송지 정보’, ‘주문자’, ‘주문목록’, ‘총결제 금액’ 의 하위 모델로 구성되는데 이때 이 하위 개념을 표현한 모델을 하나로 묶어서 ‘주문’이라는 상위 개념으로 표현할 수 있다.

• 애그리거트를 사용하면 개별 객체가 아닌 관련 객체를 묶어서 객체 군집 단위로 모델을 바라볼 수 있게 된다.

• 개별 객체 간의 관계가 아닌 애그리거트 간의 관계로 도메인 모델을 이해하고 구현할 수 있게 되며, 이를 통해 큰 틀에서 도메인 모델을 관리할 수 있게 된다.

• 애그리거트는 군집에 속한 객체들을 관리하는 루트 엔티티를 갖는다.
• 루트 엔티티는 애그리거트에 속해 있는 엔티티와 밸류 객체를 이용해서 애그리거트가 구현해야 할 기능을 제공한다.
• 애그리거트를 사용하는 코드는 애그리거트 루트가 제공하는 기능을 실행하고 애그리거트 루트를 통해서 간접적으로 애그리거트 내의 다른 엔티티나 밸류 객체에 접근하게 된다.
• 이는 애그리거트의 내부 구현을 숨겨서 애그리거트 단위로 구현을 캡슐화할 수 있도록 돕는다.

• 위 이미지는 주문 애그리거트를 보여주고 있다.
• 애그리거트 루트인 Order는 주문 도메인 로직에 맞게 애그리거트의 상태를 관리한다.
• 예를 들어, Order의 배송지 정보 변경 기능은 배송지를 변경할 수 있는지 확인한 뒤에 배송지 정보를 변경한다.

1
2
3
4
5
6
7
8
9
10
11

public class Order {
 ...
 public void changeShippingInfo(ShippingInfo shippinginfo) {
  checkShippingInfoChangeable(); // 배송지 변경 가능 여부 확인
  this.shippingInfo = newInfo;
 }

 private Boolean checkShippingInfoChangeable() {
  ... 배송지 정보를 변경할 수 있는지 여부를 확인하는 도메인 규칙 구현
 }
}

• checkShippingInfoChangeable() 메서드는 도메인 규칙에 따라 배송지를 변경할 수 있는지 확인할 것이다.
  • 예를 들어, 이미 배송이 시작된 경우 익셉션을 발생하는 식으로 도메인 규칙을 구현할 것이다.
• 주문 애그리거트는 Order 를 통하지 않고 ShippingInfo를 변경할 수 있는 방법을 제공하지 않는다.
  • 즉, 배송지를 변경하려면 루트 엔티티인 Order 를 사용해야 하므로 배송지 정보를 변경시엔 Order 가 구현한 로직을 항상 따르게 된다.
• 애그리거트를 구현할 떈 고려할 것이 많다.
  • 애그리거트를 어떻게 구성했느냐에 따라 구현이 복잡해지기도 하고 트랜잭션 범위가 달라지기도 한다.
  • 또한 선택한 구현 기술에 따라 애그리거트 구현에 제약이 생기기도 한다.
  • 애그리거트의 구현에 대한 내용은 3장에서 자세히 다룬다.

리포지터리

• 도메인 객체를 지속적으로 사용하기 위해서는 RDBMS, NoSQL, 로컬 파일과 같은 물리적인 저장소에 도메인 객체를 보관해야한다.
• 이를 위한 도메인 리포지터리이다.
• 리포지터리는 애그리게이트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의한다.

1
2
3
4
5

public interface OrderRepository {
  public Order findByNumber(OrderNumber number);
  public void save(Order order);
  public void delete(Order order);
}

• 도메인 모델을 사용해야 하는 코드(주로 응용 서비스 영역의 코드일 것이다) 는 리포지토리를 통해 도메인 객체를 구한 뒤 도메인 객체의 기능을 실행하게 된다.

1
2
3
4
5
6
7
8
9

public class CancelOrderService {
  private OrderRepository orderRepository; // DI

  public void cancel(OrderNumber number) {
    Order order = orderRepository.findByNumber(number);
    if (order == null) throw new NoOrderException(number);
    order.cancel();
  }
}

• 도메인 모델 관점에서 OrderRepository 는 도메인 객체를 영속화하는데 필요한 기능을 추상화한 것으로 고수준 모델에 속한다.
• 기반 기술을 이용해 OrderRepository를 구현한 클래스는 저수준 모듈로 인프라스트럭처 영역에 속한다.
• 즉, 모듈 구조는 아래 이미지와 같을 것이다.

요청 처리 흐름

• 표현 영역은 사용자가 전송한 데이터 형식을 올바른지 검사하고 문제가 없다면 데이터를 이용해서 으용 서비스에 기능 실행을 위임한다.
• 이떄 표현 영역은 사용자가 전송한 데이터를 응용 서비스가 요구하는 형식으로 변환해서 전달한다.
  • RQ 모델을 그대로 응용 서비스에 전달하는게 아닌 validation 체크 후 도메인 모델로 컨버팅해서 전달하는 방식이 될 것이다.
• 웹 브라우저를 이용해서 기능 실행을 요청할 경우, 아래 이미지처럼 표현 영역에 해당하는 컨트롤러는 과정1.1처럼 HTTP 요청 파라미터를 응용 서비스가 필요로 하는 데이터로 변환 후 응용 서비스를 실행할 떄 파라미터로 전달한다.

• 응용 서비스는 도메인 모델을 이용해 기능을 구현한다.
• 기능 구현에 필요한 도메인 객체를 리포지토리에서 가져와 실행하거나 신규 도메인 객체를 생성해서 리포지터리에 쩌장한다.
  • 두 개 이상의 도메인 객체를 사용해서 구현하기도 한다.
• 응용 서비스의 역할 중 하나는 아래 코드와 같이 트랜잭션을 관리하는 것이다.

1
2
3
4
5
6
7
8
9
10

public class CancelOrderService {
  private OrderRepository orderRepository; // DI

  @Transactional // 응용 서비스는 트랜잭션을 관리한다.
  public void cancel(OrderNumber number) {
    Order order = orderRepository.findByNumber(number);
    if (order == null) throw new NoOrderException(number);
    order.cancel();
  }
}

인프라스트럭처 개요

• 인프라스트럭처는 표현 영역, 응용 영역, 도메인 영역을 지원한다.
• 도메인 객체의 영속성 처리, 트랜잭션, SMTP 클라이언트, REST 클라이언트 등 다른 영역에서 필요로 하는 프레임워크, 구현 기술, 보조 기능을 지원한다.

• DIP에서 언급했듯이 도메인 영역과 응용 영역이 인프라스트럭처의 기능을 직접 사용하는 것보다, 이 두 영역에 정의한 인터페이스를 인프라스트럭처 영역에서 구현하는 것이 시스템을 더 유연하고 테스트하기 쉽게 만들어준다.

• 하지만, 무조건 인프라스트럭처에 대한 의존을 없애는 것이 좋은 것은 아니다.
• 예를 들어, 스프링을 사용할 경우 응용 서비스는 트랜잭션 처리를 위해 스프링에 제공하는 @Transactional 을 사용하는 것이 편리하다.
• 영속성 처리를 위해 JPA를 사용할 경우 @Entity 나 @Table과 같은 JPA 전용 애노테이션을 도메인 모델 클래스에 사용하는 것이 XML 매핑 설정을 이용하는 것보다 편리하다.

1
2
3
4
5
6
7
8

// 구현의 편리함을 위해ㅣ 인프라스트럭처에 대한 의존을 일부 도메인에 넣은 코드
// JPA의 @Table 애노테이션을 이용해서 엔티티를 저장할 테이블 이름을 지정했다.
// XML 설정 보다 편리하게 테이블 이름을 지정 가능하다.
@Entity
@Table(name = "TBL_ORDER")
public class Order {

}

• 구현의 편리함은 DIP가 주는 다른 장점(변경의 유연함, 테스트가 쉬움) 만큼 중요하기 떄문에 DIP의 장점을 해치지 않는 범위에서 응용 영역과 도메인 영역에서 구현 기술에 대한 의존을 가져가는 것이 현명하다.
• 응용 영역과 도메인 영역이 인프라스트럭처에 대한 의존을 완전히 갖지 않도록 시도하는 것은 자칫 구현을 더 복잡하고 어렵게 만들 수 있다.
• 예를 들어, 스프링의 @Transaction 어노테이션을 사용하면 한 줄로 트랜잭션을 처리할 수 있는데, 코드에서 스프링에 대한 의존을 없애려면 복잡한 스프링 설정을 사용해야 한다.
  • 의존은 없애지만 특별히 테스트를 더 쉽게 할 수있다거나 유연함을 증가 시켜주지 못한다. 단지 설정만 복잡해지고 개발 시간만 늘어날 뿐이다…

모듈 구성

• 아키텍처의 각 영역은 패키지에 위치한다.
• 패키지 구성 규칙에 한 개의 정답만 존재하는 것은 아니지만 아래와 같이 영역별로 모듈이 위치할 때 패키지를 구성할 수 있을 것이다.

• 도메인이 크면 아래 이미지의 [그림 2.22]와 같이 하위 도메인으로 나누고 각 하위 도메인마다 별도 패키지를 구성한다.

• domain 모듈은 도메인에 속한 애그리거트를 기준으로 다시 패키지를 구성한다.
  • 예를 들어, 카탈로그 하위 도메인을 위한 도메인은 상품 애그리거트와 카테고리 애그리거트로 구성된다고 할 경우, [그림 2.23] 과 같이 domain을 두 개의 하위 패키지로 구성해볼 수 있다.

• 각 애그리거트와 모델과 리포지토리는 같은 패키지에 위치시킨다.
  • 예를 들어, 주문고 ㅏ관련된 Order, OrderLine, OrderRepository 등은 com.myshop.order.domain 패키지에 위치시킨다.
• 도메인이 복잡하면 도메인 모델과 도메인 서비스를 다음과 같이 별도 패키지에 위치시킬 수도 있다.

1
2

com.myshop.order.domain.order: 애그리거트 위치
com.myshop.order.domain.servicee: 도메인 서비스 위치

응용 서비스도 다음과 같이 도메인 별로 패키지를 구분할 수 있다.

1
2

com.myshop.catalog.application.product
com.myshop.catalog.application.category

Note: 모듈 구조를 얼마나 세분화 할지에 대해서는 정해진 규칙은 없다. 한 패키지에 너무 많은 타입이 몰려서 코드를 찾을 때 불편한 정도만 아니면 된다. 저자는 한 패키지에 가능하면 10개 미만으로 타입 개수를 유지하려고 노력한다고 한다. 이 개수가 넘어가면 모듈을 분리하는 시도를 해보자.

애그리거트

• 백 개이상의 테이블을 한장의 ERD에 모두 표시하면 개별 테이블 간의 관계를 파악하느라 큰 틀에서 데이터 구조를 이해하는데 어려움을 겪게 되는 것처럼, 도메인 객체 모델이 복잡해지면 개별 구성요소 위주로 모델을 이해하게 되고 전반적인 구조나 큰 수준에서 도메인 간의 관계를 파악하기 어려워진다.
• 주요 도메인 개념 간의 관계를 파악하기 어렵다는 것은 곧 코드를 변경하고 확장하는 것이 어려줘진다는 것을 의미한다.
  • 상위 수준에서 모델이 어떻게 엮여 있는지 알아야 전체 모델을 망가뜨리지 않으면서 추가 요구사항을 모델에 반영할 수 있는데 세부적인 모델만 이해한 상태론 코드를 수정하기가 두렵기 때문에 코드 변경을 최대한 회피하는 쪽으로 요구사항을 협의하게 된다.
  • 꼼수를 부려 당장 돌아가는 코드를 추가할 순 있지만 이는 장기적인 관점에서 코드를 더 수정하기 어렵게 만들기도 한다.
• 복잡한 도메인을 이해하고 관리하기 쉬운 단위로 만들려면 상위 수준에서 모델을 조망할 수 있는 방법이 필요한데, 그 방법이 애그리거트이다.
• 앞선 쳅터에서 언급한 것처럼 애그리거트는 관련된 객체를 하나의 군으로 묶어준다.

• 위 이미지는 앞선 모델들을 애그리거트로 묶어서 다시 표현한 것인데, 동일한 모델이지만 애그리거트를 사용함으로써 모델 간의 관계를 개별 모델 수준뿐 아닌 상위 수준에서도 이해할 수 있게 된다.

• 애그리거트는 또한 일관성을 관리하는 기준이 된다.
  • 이로 인해 애그리거트는 복잡한 도메인을 단순한 구조로 만들어준다.
  • 이는 복잡도가 낮아지는 만큼 도메인 기능을 확장하고 변경하는데 필요한 노력(개발 시간)도 줄어든다.
• 애그리거트는 관련된 모델을 하나로 모은 것이기 때문에 한 애그리거트에 속한 객체는 유사하거나 동일한 라이프사이클을 갖는다.
  • 주문 애그리거트를 만드려면 Order, OrderLine, Orderer 와 같은 관련 객체를 함께 생성해야 한다.
• 도메인 규칙에 따라 최초 주문 시점에 일부 객체를 만들 필요가 없는 경우도 있지만 애그리거트에 속한 구성요소는 대부분 함꼐 생성하고 함께 제거한다.

애그리거트가 가지는 책임

• 위 이미지에서 본 것처럼 애그리거트는 경계를 갖는다.
• 한 애그리거트에 속한 객체는 다른 애그리거트에 속하지 않는다. 즉 독립된 객체 군이며, 각 애그리거트는 자기 자신을 관리할 뿐 다른 애그리거트를 관리하지 않는다.
• 예를 들어, 주문 애그리거트는 배송지를 변경하거나 주문 상품 개수를 변경하는 등 자기 자신을 관리하지만, 회원의 비밀번호를 변경하거나 상품의 가격을 변경하진 않는다.

애그리거트의 경계를 어떻게 나누느냐

• 경계를 설정할 때 기본이 되는 것은 도메인 규칙과 요구사항이다.
  • 도메인 규칙에 따라 함께 생성되는 구성요소는 한 애그리거트에 속할 가능성이 높다.
  • 예를 들어, 주문할 상품 개수, 배송지 정보, 주문자 정보는 주문 시점에 함께 생성되므로 이들은 한 애그리거트에 속한다.
  • 또한, OrderLine의 주문 상품 개수를 변경시 도메인 규칙에 따라 Order의 총 주문 금액도 새로 계산해야 한다.
  • 사용자 요구사항에 따라 주문 상품 개수와 배송지를 함께 변경하기도 한다.
  • 이렇게 하면 함께 변경되는 비녿가 높은 객체는 한 애그리거트에 속할 가능성이 높다.
• 흔히 ‘A가 B를 갖는다’ 로 설계할 수 있는 요구사항이 있다면 A와 B를 한 애그리거트로 묶어서 생각하기 쉽다.
  • 주문의 경우 Order가 ShippingInfo와 Orderer를 가지므로 이는 어느 정도 타당해 보인다.
  • 하지만 ‘A가 B를 갖는다’로 해석할 수 있는 요구사항이 있따하더라도 이것이 반드시 A와 B가 한 애그리거트에 속한다는 것을 의미하는 것은 아니다.
  • 좋은 예가 상품과 리뷰다. 상품 상세 페이지에 들어가면 상품 상세 정보와 함꼐 리뷰 내용을 보여줘야 한다는 요구사항이 있다면 Product 엔티티와 Review엔티티가 한 애그리거트에 속한다 생각할 수 있지만 이 둘은 함께 생성되지 않고 함께 변경되지 않는다.
  • 게다가 Product 를 변경하는 주체가 상품 담당자라면 Review를 생성하고 변경하는 주체는 고객이다.

• Review의 변경이 Product에 영향을 주지 않고 반대로 Product의 변경이 Review에 영향을 주지 않기 떄문에 이 둘은 한 애그리거트에 속한다기보다는 [그림 3.3]에 표시한 것처럼 서로 다른 애그리거트에 속한다.
• 처음 도메인 모델을 만들기 시작하면 큰 애그리거트로 보이는 것들이 많지만 도메인에 대한 경험이 생기고 도메인 규칙을 제대로 이해할수록 실제 애그리거트의 크기는 줄어들게 된다.
  • 저자의 경험을 비추어보면 다수의 애그리거트가 한 개의 엔티티 객체만 갖는 경우가 많으며 두 개 이상의 엔티티로 구성되는 애그리거트는 드물게 존재한다고 한다.

애그리거트 루트

• 애그리거트는 여러 객체로 구성되기 때문에 반드시 모든 객체들의 상태가 정상이어야 한다.
  • 예를 들어, 개별 구매 상품의 개수인 quantity와 금액 price를 가지는 OrderLine과 Order 객체의 총 주문 금액 totalAmounts 는 정합성이 맞아들어야 한다.
• 애그리거트에 속한 모든 객체가 일관된 상태를 유지하려면 애그리거트 전체를 관리할 주체가 필요한데 이 책임을 지는 것이 바로 애그리거트의 루트 엔티티다.
  • 위 이미지에선 Order 가 애그리거트 루트 역할을 한다 볼 수 있다.

도메인 규칙과 일관성

• 애그리거트 루트의 핵심 역할은 애그리거트의 일관성이 깨지지 않도록 하는 것이다.
  • 이를 위해 애그리거트 루트는 애그리거트가 제공해야 할 도메인 기능을 구현한다.
  • 예를 들어, 주문 애그리거트는 배송지 변경, 상품 변경과 같은 기능을 제공하는데 Order가 이 기능을 구현한 메서드를 제공한다.
• 애그리거트 루트가 제공하는 메서드는 도메인 규칙에 따라 애그리거트에 속한 객체의 일관성이 깨지지 않도록 구현해야 한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Order{
	
  // 애그리거트 루트는 도메인 규칙을 구현한 기능을 제공한다.
	public void changeShippingInfo(ShippingInfo newShippingInfo) {
		verifyNotYetShipped(); // 출고 전에만 배송지 변경을 할 수 있다는 규칙을 구현
		setShippingInfo(newShippingInfo);
	}
	
	private void verifyNotYetShipped(){
		if(state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING)
			throw new IllegalStateException("already shippped");
	}
	...
}

• 애그리거트 루트가 아닌 다른 객체가 애그리거트에 속한 객체를 직접 변경하면 안된다.
  • getter를 무분별하게 만들었을 때 발생하는 문제점 중 하나이다.
• 이는 애그리거트 루트가 강제하는 규칙을 적용할 수 없어 모델의 일관성을 깨는 원인이 된다.

1
2

ShippingInfo si = order.getShippingInfo();
si.setAddress(newAddress);

• 위 코드는 주문 상태와 관계 없이 배송지 주소를 변경하게 되는데 논리적인 데이터 일관성이 꺠지게 된다.
• 일관성을 지키기 위해 상태 확인 로직을 응용 서비스에서 구현할 수 도 있지만, 이렇게 되면 동일한 검사 로직을 여러 응용 서비스에서 중복 구현할 가능성이 높아져 상황을 더 악화시킬 수 있다.
  • 유지보수성이 떨어지게되고 막 예시를 들어 주소 변경 도메인 규칙이 추가되거나 변경될 경우 일일이 다 찾아서 처리를 해줘야 될 것이다..

1
2
3
4
5
6
7

ShippingInfo si = order.getShippingInfo();

// 주요 도메인 로직이 중복되는 문제
if(state != OrderState.PAYMENT_WAITING && state != OrderState.PREPARING)
			throw new IllegalStateException("already shippped");

si.setAddress(newAddress);

불필요한 중복을 피하고 애그리거트 루트를 통해서만 도메인 로직을 구현하게 만들기 위한 두 가지 습관

1. 단순히 필드를 변경하는 set메서드를 공개 (public) 범위로 만들지 않는다.

1
2
3
4

// 도메인 모델에서 공개 set 메서드는 가급적 피해야 한다.
public void setName(String name) {
  this.name = name;
}

• 공개 set 메서드는 중요 도메인의 의미나 의도를 표현하지 못하고 도메인 로직이 도메인 객체가 아닌 응용 표현 영역으로 분산되게 만드는 원인이 된다.
  • 도메인 로직이 한 곳에 응집되어 있지 않게 되므로 코드를 유지보수할 때에도 분석하고 수정하는데 더 많은 시간을 들이게 된다.
• 도메인 모델의 엔티티나 밸류에 공개 set 메서드만 넣지 않아도 이로간성이 깨질 가능성이 줄어든다.
  • 공개 set 메서드를 사용하지 않게 되면 의미가 드러나는 메서드를 사용해서 구현할 가능성이 높아진다.
  • 예를 들어, set 형식의 이름을 갖는 공개 메서드를 사용하지 않으면 자연스럽게 cancel이나 changePassword 처럼 의미가 더 잘 드러나는 이름을 사용하는 빈도가 높아진다.

2. 벨류 타입은 불변으로 구현한다.

• 밸류 객체의 값을 변경할 수 없으면 애그리거트 루트에서 밸류 객체를 구해도 값을 변경할 수 없기에 애그리거트 외부에서 밸류 객체의 상태를 변경할 수 없게 된다.

1
2
3

ShippingInfo si = order.getShippingInfo();

si.setAddress(newAddress); // ShippingInfo 벨류 객체가 불변이면 컴파일 에러 발생!

• 애그리거트 외부에서 내부 상태를 함부로 바꾸지 못하므로 애그리거트의 이로간성이 꺠질 가능성이 줄어든다.
• 즉, 다음과 같이 애그리거트 루트가 제공하는 메서드에 새로운 벨류 객체를 적달해서 값을 변경하는 방법 밖에 없다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class Order{
	
	public void changeShippingInfo(ShippingInfo newShippingInfo) {
		verifyNotYetShipped();
		setShippingInfo(newShippingInfo);
	}
	
  // set 메서드의 접근 허용 범위는 private이다.
  private void setShippingInfo(ShippingInfo shippingInfo) {
    // 벨류가 불변이면, 새로운 객체를 할당해서 값을 변경해야 한다.
    // 불변이므로 this.shippingInfo.setAddress(newShippingInfo.getAddress())와 같은 코드를 사용할 수 없다.
    this.shippingInfo = shippingInfo;
  }
}

애그리거트 루트의 기능 구현

• 애그리거트 루트는 애그리거트 내부의 다른 객체를 조합해서 기능을 완성한다.
  • 예를 들어, Order는 총 주문 금액을 구하기 위해 OrderLine 목록을 사용한다.

1
2
3
4
5
6
7
8
9
10
11
12

public class Order {
  private Money money;
  private List<OrderLine> orderLines;

  private void calculateTotalAmounts() {
    int sum = orderLine.stream()
                       .mapToInt(o1 -> o1.getPrice() * o1.quantity())
                       .sum();

    this.totalAmounts = new Money(sum);
  }
}

• 또한 기능 실행을 위임하기도 한다.
  • Order의 changeOrderLines() 메서드는 내부의 orderLines 필드에 상태변경을 위임하는 방식으로 구현한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

public class Order {
  private OrderLines orderLines;

  private void changeOrderLines(List<OrderLine> newOrderLines) {
    orderLines.changeOrderLines(newOrderLines);
    this.totalAmounts = orderLines.getTotalAmounts;
  }
}

public class OrderLines {
  private List<OrderLine> lines;

  public Money getTotalAmounts() {
    ...
  };

  private void changeOrderLines(List<OrderLine> newLines) {
    this.lines = newLines;
  }
}

• 만약 Order가 getOrderLines()와 같이 OrderLine를 구할 수 있는 메서드를 제공하면 애그리거트 외부에서 OrderLines의 기능을 실행할 수 있게 된다.

1
2
3
4
5

OrderLines lines = order.getOrderLines();

// 외부에서 애그리거트 내부 상태 변경!
// order의 totalAmounts가 값이 OrderLines가 일치하지 않게 됨
lines.changeOrderLines(newOrderLines);

• 이 코드는 주문의 OrderLine 목록이 바뀌는데 총합은 계산하지 않는 버그를 만든다.
  • 이런 버그를 생기지 않도록 하려면 애초에 애그리거트 외부에서 OrderLine 목록을 변경할 수 없도록 OrderLines를 불변으로 구현하면 된다.
• 팀 표준이나 구현 기술의 제약으로 OrderLines를 불변으로 구현할 수 없다면 OrderLines의 변경 기능을 패키지나 protected 범위로 한정해서 외부에서 실행할 수 없도록 제한하는 방법이 있다.
  • 보통 한 애그리거트에 속하는 모델은 한 패키지에 속하기 때문에 패키지나 protected 범위를 사용하면 애그리거트 외부에서 상태 변경 기능을 실행하는 것을 방지 할 수 있다.

트랜잭션 범위

• 트랜잭션의 범위는 작으면 작을 수록 좋다.
  • DB 테이블을 기준으로 한 트랜잭션이 한개의 테이블을 수정하는 것과 세 개의 테이블을 수정하는 것은 성능에서 차이가 발생한다.
  • 한 개의 테이블을 수정할 땐 트랜잭션 충돌을 막기 위해 잠그는 대상이 한 개 테이블의 한 행으로 한정되지만, 세 개의 테이블을 수정하면 잠금 대상이 더 많아진다.
  • 잠금 대상이 많아진다는 것은 그만큼 동시에 처리할 수 있는 트랜잭션 개수가 줄어든다는 것을 뜻하고 전체적인 성능(처리량)을 떨어뜨린다.
• 동일하게 한 트랜잭션에선 한 개의 애그리거트만 수정해야 한다.
  • 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하면 트랜잭션 충돌이 발생할 가능성이 더 높아지기 때문에 한 번에 수정하는 애그리거트 개수가 많아질수록 전체 처리량이 떨어지게 된다.
• 한 트랜잭션에서 한 애그리거트만 수정한다는 것은 애그리거트에서 다른 애그리거트를 변경하지 않는다는 것을 뜻한다.
  • 한 애그리거트에서 다른 애그리거트를 수정하면 결과적으로 두 개의 애그리거트를 한 트랜잭션에서 수정하게 되므로 한 애그리거트 내부에서 다른 애그리거트의 상태를 변경하는 기능을 실행하면 안된다.
  • 예를 들어, 배송지 정보를 변경하면서 동시에 배송지 정보를 회원의 주소로 설정하는 기능이 있따고 해보자.
  • 이 경우 주문 애그리거트는 다음과 같이 회원 애그리거트의 정보를 변경해선 안된다.

1
2
3
4
5
6
7
8
9
10
11
12

public class Order {
  private Orderer orderer;

  public void shipTo(ShippingInfo shippingInfo, boolean useNewShippingAddrAsMemberAddr) {
    verifyNotYetShipped();
    setShippingInfo(newShippingInfo);
    if (useNewShippingAddrAsMemberAddr) {
      // 다른 애그리거트의 상태를 변경하면 안됨!
      order.getOrderer().getCustomer().changeAddress(newShippingInfo.getAddress());
    }
  }
}

• 이는 애그리거트가 자신의 책임 범위를 넘어 다른 애그리거트의 상태까지 관리하는 꼴이 된다.
• 애그리거트는 서로 최대한 독립적이어야 하는데 한 애그리거트가 다른 애그리거트의 기능에 의존하기 시작하면 애그리거트 간의 결합도가 높아지게 된다.
  • 결합도가 높아지면 높아질수록 향후 수정 비용이 증가하므로 애거리트에서 다른 애그리거트의 상태를 변경하지 말아야 한다.
• 만약 한 트랜잭션에서 두 개 이상의 애그리거트를 수정해야한다면 아래와 같이 응용 서비스에서 두 애그리거트를 수정하도록 하자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class ChangeOrderService {
 @Transactional
 public void changeShippingInfo(OrderId id,
  ShippingInfo newShippingInfo,
  boolean useNewShippingAddrAsMemberAddr) {

  Order order = orderRepository.findbyId(id);
  if (order == null) throw new OrderNotFoundException();
  order.shipTo(newShippingInfo);

  if (useNewshippingAddrAsMemberAddr) {
   order.getOrderer()
    .getCustomer().changeAddress(newShippingInfo.getAddress());
  }
 }
 ...
}

• 도메인 이벤트를 사용하면 한 트랜잭션에서 한 개의 애그리거트를 수정하면서도 동기나 비동기로 다른 애그리거트의 상태를 변경할 수 있다. 관련된 내용은 10장에서 살펴보자.

• 기본적으로 한 트랜잭션에서 하나의 애그리거트를 수정하는 것을 권장하지만, 다음의 경우에는 두 개 이상의 애그리거트를 변경하는 것을 고려해볼 수 있다.

  • 1)팀 표준 : 조직의 표준에 따라 사용자 유스케이스와 관련된 응용 서비스의 기능을 한 트랜잭션으로 실행해야 하는 경우
  • 2)기술 제약 : 한 트랜잭션에서 두 개 이상의 애그리거트를 수정하는 대신 도메인 이벤트와 비동기를 사용하는 방식을 사용하는데, 기술적으로 이벤트 방식을 도입할 수 없는 경우 한 트랜잭션에서 다수의 애그리거트를 수정해서 일관성을 처리해야 한다.
  • 3)UI 구현의 편리 : 운영자의 편리함을 위해 주문 목록 화면에서 여러 주문의 상태를 한 번에 변경하고 싶을 경우

리포지터리와 애그리거트

• 리포지터리는 애그리거트 단위로 존재한다,
  • Order와 OrderLine을 물리적으로 각각 별도의 DB테이블에 저장한다고 해서 Order 와 OrderLine을 위한 리포지터리를 각각 만들지 않는다. Order가 애그리거트 루트이고 OrderLine인 애그리거트에 속하는 구성요소이므로 Order 를 위한 리포지토리만 존재한다.
• ORM 기술 중의 하나인 JPA/Hibernate 를 사용하면 DB관계형 모델에 객체 도메인 모델을 맞춰야 하는 경우도 있다.
  • 특히 레거시 DB를 사용해야 하거나 팀 내 DB 설계 표준을 따라야 한다면 DB 테이블 구조에 맞게 모델을 변경해야 한다.
  • 이 경우 밸류 타입인 도메인 모델을(JPA에서 밸류 타입을 매핑할 떄 사용하는) @Component 가 아닌 (엔티티를 매핑할 때 사용하는) @Entity를 이용해야 할 수도 있다.
• 애그리거트는 개념적으로 하나이므로 리포지터리는 애그리거트 전체를 저장소에 영속화해야 한다.
  • 예를 들어, Order 애그리거트와 관련된 테이블이 세 개라면 리포지터리를 통해서 Order 애그리거트를 저장할 떄 애그리거트 루트와 매핑되는 테이블뿐만 아니라 애그리거트에 속한 모든 구성요소를 위한 테이블에 데이터를 저장해야 한다.

1
2

// 리포지토리에 애그리거트를 저장하면 애그리거트 전체를 영속화해야 한다.
orderRepository.save(order);

• 위와 동일하게 애그리거트를 구하는 리포지터리 메서드는 완전한 애그리거트를 제공해야 한다.
  • 즉 다음 코드를 실행시 order 애그리거트는 OrderLine, Orderer 등 모든 구성요소를 포함하고 있어야 한다.
  • 그렇지 않을 경우 NPE 가 발생하게 된다.

1
2
3
4
5
6

// 리포지토리는 완전한 order를 제공해야 한다.
Order order = orderRepository.findById(orderId);

// order가 온전한 애그리거트가 아니면
// 기능 실행 도중 NPE 가 발생한다.
order.cancel();

• 애그리거트를 영속화할 저장소로 무엇을 사용하든지 간에(RDBMS, Mongo DB, HBase) 애그리거트의 상태가 변경되면 모든 변경을 원자적으로 저장소에 반영해야 한다. 데이터 일관성을 보장하는 것이 중요하다.
  • RDBMS와 JPA를 이용한 리포지토리와 애그리거트의 구현에 대한 내용은 4장에서 살펴볼 예정이다.

ID를 이용한 애그리거트 참조

• 애그리거트는 다른 애그리거트를 참조한다.
  • 애그리거트의 관리 주체가 애그리거트 루트이므로 애그리거트에서 다른 애그리거트를 참조한다는 것은 애그리거트의 루트를 참조한다는 것과 같다.

다른 애그리거트 필드 참조

• 예를 들어, 주문 애그리거트에 속해 있는 Orderer 는 [그림 3.6]처럼 주문한 회원을 참조하기 위해 회원 애그리거트 루트인 Member를 필드로 참조할 수 있다.

• 필드를 이용해서 다른 애그리거트를 직접 참조하는 것은 개발자에게 구현의 편리함을 제공한다.
  • 예를 들어, 주문 정보 조회 화면에서 회원 아이디를 이용해서 링크를 제공해야 한다고 해보자.
  • 이 경우, 다음과 같이 Order로부터 시작해서 회원 아이디를 구할 수 있다.

1

order.getOrderer().getMember().getId();

• JPA를 사용하면 @ManyToOne, @OneToOne 과 같은 어노테이션을 이용해서 연관된 객체를 로딩하는 기능을 제공하고 있으므로 필드를 이용해서 다른 애그리거트를 쉽게 참조할 수 있다.

다른 애그리거트 필드 참조의 문제점

1) 편한 탐색 오용

• 가장 큰 문제점이다.
• 한 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다른 애그리거트의 상태를 쉽게 변경할 수 있게 된다.
• 트랜잭션 범위에서 언급한 것처럼 한 애그리거트가 관리하는 범위는 자기 자신으로 한정해야 한다.
• 그런데, 애그리거트 내부에서 다른 애그리거트 객체에 접근할 수 있으면 다음 코드처럼 구현의 편리함 때문에 다른 애그리거트를 수정하고자 하는 유혹에 빠지기 쉽다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class Order {
    private Orderer orderer;
    
    public void changeShippingInfo(ShippingInfo newShippingInfo, 
        boolean useNewShippingAddrAsMemberAddr) {
        ...
        if(useNewShippingAddrAsMemberAddr) {
        
            // 한 애그리거트 내부에서 다른 애그리거트에 접근할 수 있으면
            // 다른 애그리거트의 상태를 변경하는 유혹에 빠지기 쉽다.
            orderer.getCustomer().changeAddress(newShippingInfo.getAddress());
        }
        ...
    }
}

• 트랜잭션 범위에서 말한 것철검, 한 애그리거트에서 다른 애그리거트의 상태를 변경하는 것은 애그리거트 간의 의존 결합도를 높여서 결과적으로 애그리거트의 변경을 어렵게 만든다.

2) 성능에 대한 고민

• JPA를 사용할 경우 참조한 객체를 지연(Lazy)로딩과 즉시(Eager) 로딩의 두 가지 방식으로 로딩할 수 있다.
• 두 로딩 방식 중 무엇을 사용할지 여부는 애그리거트의 어떤 기능을 사용하느냐에 따라 달라진다.
• 단순히 연관된 객체의 데이터를 함께 보여주어야 하면 즉시 로딩이 조회성능에 유리하지만, 애그리거트의 상태를 변경하는 기능을 실행하는 경우엔 불필요한 객체를 함꼐 로딩할 필요가 없으므로 지연 로딩이 유리하다.
• 이런 다양한 경우의 수를 고려해서 연관 매핑과 JPQL/Criteria 쿼리의 로딩 전략을 결정해야 한다.

3) 확장 어려움

• 시스템 초기엔 단일 서버에 단일 DBMS로 서비스를 제공하는 것이 가능하다.
• 문제는 사용자가 몰리기 시작하면서 발생한다.
• 사용자가 늘고 트래픽이 증가하면 자연스럽게 부하를 분산하기 위해 하위 도메인 별로 시스템을 분리하기 시작한다.
  • 이 과정에서 하위 도메인마다 서로 다른 DBMS를 사용할 가능성이 높아진다.
  • 심지어 하위 도메인마다 다른 종류의 데이터 저장소를 사용하기도 한다. 한 하위 도메인은 마리아DB를 사용하고 다른 하위 도메인은 몽고DB를 사용하는 식으로 말이다.
  • 이는 더 이상 다른 애그리거트 루트를 참조하기 위해 JPA와 같은 단일 기술을 사용할 수 없음을 의미한다.

이러한 세 가지 문제를 완화할 때 사용할 수 있는 것이 ID를 이용해서 다른 애그리거트를 참조하는 것이다.

ID를 이용해서 다른 애그리거트를 참조할 경우의 장점

• ID를 이용한 참조는 DB 테이블에서의 외래키를 사용해서 참조하는 것과 비슷하게 다른 애그리거트를 참조할 때 ID 참조를 사용한다는 점이다.

• 단, 애그리거트 내의 엔티티를 참조할 땐 객체 레퍼런스로 참조한다.

• ID 참조를 사용하면 모든 객체가 참조로 연결되지 않고 한 애그리거트에 속한 객체들만 참조로 연결된다.
• 이는 애그리거트의 경계를 명확히 하고 애그리거트 간 물리적인 연결을 제거하기 떄문에 모델의 복잡도를 낮춰준다.

• 또한 애그거트간의 의존을 제거하므로 응집도를 높여주는 효과도 있다.

• 구현 복잡도도 낮아진다.
• 다른 애그리거트를 직접 참조하지 않으므로 애그리거트 간 참조를 지연 로딩으로 할지 즉시 로딩으로 할지 고민하지 않아도 된다.
• 참조하는 애그리거트가 필요하면 응용 서비스에서 ID를 이용해서 로딩하면 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class ChangeOrderService {
  @Transactional
  public void changeShippingInfo(OrderId id,
    ShippingInfo newShippingInfo,
    boolean useNewShippingAddrAsMemberAddr) {

    Order order = orderRepository.findbyId(id);
    if (order == null) throw new OrderNotFoundException();
    order.changeShippingInfo(newShippingInfo);

    if (useNewshippingAddrAsMemberAddr) {
      // ID를 이용해서 참조하는 애그리거트를 구한다.
      Customer customer = customerRepository.findById(order.getOrderer().getCustomerId());
      customer.changeAddress(newShippingInfo.getAddress();)
    }
  }
  ...
}

• 응용 서비스에서 필요한 애그리거트를 로딩하므로 애그리거트 수준에서 지연 로딩을 하는 것과 동일한 결과를 만든다.
• ID를 이용한 참조 방식을 사용하면 복잡도를 낮추는 것과 함께 한 애그리거트에서 다른 애그리거트를 수정하는 문제를 원천적으로 방지할 수 있다.
  • 외부 애그리거트를 직접 참조하지 않기에 애초에 한 애그리거트에서 다른 애그리거트의 상태를 변경할 수 없는 것이다.
• 애그리거트별로 다른 구현 기술을 사용하는 것도 가능해진다.
  • 중요한 데이터인 주문 애그리거트는 RDBMS에 저장하고 조회 성능이 중요한 상품 애그리거트는 NoSQL에 저장할 수 있다.
  • 또한, 각 도메인을 별도 프로세스로 서비스하도록 구현할 수도 있다.

[그림3.8] 아이디로 애그리거트를 참조하면 리포지터리마다 다른 저장소를 사용하도록 구현할 떄 확장이 용이하다.

ID를 이용한 참조와 조회 성능

• 다른 애그리거트를 ID로 참조하면 참조하는 여러 애그리거트를 읽어야 할 때 조회 속도가 문제 될 수 있다.
  • 예를 들어, 주문 목록을 보여주려면 상품 애그리거트와 회원 애그리거트를 함께 읽어야 하는데, 이를 처리할 때 다음과 같이 각 주문마다 상품과 회원 애그리거트를 읽어온다고 해보자.
  • 한 DBMS에 데이터가 있다면 조인을 이용해서 한 번에 가져올 수 있음에도 주문마다 상품 저옵를 읽어오는 쿼리를 실행하게 된다.

1
2
3
4
5
6
7
8
9

Customer customer = customerRepository.findById(ordererId);
List<Order> orders = orderRepository.findByOrderer(ordererId);
List<OrderView> dtos = orders.stream()
                             .map(order -> {
                                ProductId prodId = order.getOrderLines().get(0).getProductId();
                                //  각 주문마다 첫 번째 주문 상품 정보 로딩 위한 쿼리 실행
                                Product product = productRepository.findById(prodId);
                                return new OrderView(order, customer, product);
                             }).collect(toList());

• 위 코드를 보면 Order 조회 쿼리 한 번 그리고 주문에 엮여있는 상품 조회 쿼리 N번이 발생하게 된다.
  • 이는 지연 로딩과 관련된 대표적인 문제 N+1 문제와 비슷한 문제가 발생한다.
  • N+1 조회 문제는 더 많은 쿼리를 실행해서 전체 조회 속도가 느려지는 원인이다.
• 이 문제가 발생하지 않도록 하려면 조인을 사용하도록 해야하는데 조인을 사용하는 가장 쉬운 방법은 ID 참조 방식을 객체 참조 방식으로 바꾸고 즉시 로딩을 사용하도록 매핑 설정을 바꾸는 것이다.
  • 하지만, 이 방식은 애그리거트 간 참조를 ID 참조 방식에서 객체 참조 방식으로 다시 되돌리는 것이다.
• ID 참조 방식을 사용하면서 N+1 조회와 같은 문제가 발생하지 않도록 하려면 전용 조회 쿼리 를 사용하면 된다.
  • 예를 들어, 데이터 조회를 위한 별도 DAO를 만들고 조회 메서드에서 세타 조인을 이용해서 한 번의 쿼리로 필요한 데이터를 로딩하면 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@Repository
public class JpaOrderViewDao implements OrderViewDao {
    @PersistenceContext
    private EntityManager em;

    @Override
    public List<OrderView> selectByOrder(String ordererId) {
        String selectQuery =
            "select new com.myshop.order.application.dto.OrderView(o, m, p) " +
            "from Order o join o.orderLines ol, Member m, Product p " +
            "where o.orderer.memberId.id = :ordererId " +
            "and o.orderer.memberId = m.id " +
            "and ol.productId = p.id " +
            "order by o.number.number desc";

        TypedQuery<OrderView> query =
            em.createQuery(selectQuery, OrderView.class);
        query.setParameter("ordererId", ordererId);
        return query.getResultList();
    }
}

• 이 JPQL은 Order 애그리거트와 Member 애그리거트, 그리고 Product 애그리거트를 세타 조인으로 조회해서 한 번의 쿼리로 로딩한다.
  • 즉시 로딩이나 지연로딩과 같은 로딩 전략을 고민할 필요 없이 조회 화면에서 필요한 애그리거트 데이터를 한 번의 쿼리로 로딩할 수 있다.
  • 쿼리가 복잡하거나 SQL에 특화된 기능을 사용해야 한다면 조회를 위한 부분만 MyBatis 와 같은 기술을 이용해서 실행할 수도 있다.

Note: JPA를 사용하면 각 객체 간 모든 연관을 지연/즉시로딩으로 어떻게든 처리하고 싶은 욕구가 생길텐데 이는 실용적이지 않다. ID를 이용해서 애그리거트를 참조해도 한 번의 쿼리로 필요한 데이터를 로딩하는 것이 가능하다.

• 애그리거트마다 서로 다른 저장소를 사용하는 경우엔 한 번의 쿼리로 관련 애그리거트를 조회할 수 없다.
• 이런 경우 조회 성능을 높이기 위해 캐시를 적용하거나 조회 전용 저장소를 따로 구성한다.
  • 이 방법은 코드가 복잡해지는 단점이 있지만, 시스템의 처리량을 높일 수 있는 장점이 있다.
• 특히 한 대의 DB 장비로 대응할 수 없는 수준의 트래픽이 발생하는 경우 캐시나 조회 전용 저장소는 필수로 선택해야 한다.

애그리거트 간 집합 연관

1:N

• 한 카테고리에 여러 상품이 속할 수 있으니 1:N 관계이다.

1
2
3
4
5
6
7
8

public class Category {
    private Set<Product> products;  //  다른 애그리거트에 대한 1:N 연관
    //...
    public List<Product> getProducts(int page, int size) {
        List<Product> sortedProducts = sortById(products);
        return sortedProducts.subList((page - 1) * size, page * size);
    }
}

• 하지만 위처럼 도메인 객체 내에 연관을 맺게 되면 해당 객체가 불릴때마다 Category에 속한 모든 Product를 조회하게 되면서 성능에 심각한 문제를 야기시킨다.
  • Product 의 갯수가 수백에서 수만 개정도로 많다면…
• 따라서 개념적으로는 애그리거트 간에 1:N 연관이 있다고 하더라도 성능상 문제로 인해 애그리거트 간의 1:N 연관을 실제 구현에 반영하는 경우는 드물다.
• 이에 대한 해결책으로 상품 입장에서 자신이 속한 카테고리를 N:1 로 연관지어 구하면 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

public class Product {
    // ...
    private CateogryId category;
    //...
}

public class ProductListService {
    public Page<Product> getProductOfCategory(Long categoryId, int page, int size) {
        Category category = categoryRepository.findById(categoryId);
        checkCategory(category);
        List<Product> products = productRepository.findByCategoryId(category.getId(), page, size);
        int totalCount = productRepository.countByCategoryId(category.getId());
        return new Page(page, size, totalCount, products);
    }
}

• 카테고리에 속한 상품 목록을 제공하는 응용 서비스는 다음과 같이 ProductRepository를 이용해 CategoryId가 지정한 카테고리 식별자인 Product 목록을 구한다.

M:N

• 상품이 여러 카테고리에 속할 수 있다고 가정하면 카테고리와 상품은 M:N 연관을 맺는다.
• M:N 연관은 개념적으로 양쪽 애그리거트에 컬랙션으로 연관을 만든다.
  • 하지만 앞선 1:N 처럼 요구사항을 고려해서 M:N 연관을 구현에 포함시킬지 여부를 결정해야 한다.
• 일반적으로 상품 페이지를 보여줄 때 각 상품 별 모든 카테고리 정보를 다 보여주진 않는다.
  • 상품 상세 화면에서 주로 카테고리 정보를 보여주게 된다.
  • 이 요구사항을 고려하면 카테고리 -> 상품의 연관은 필요하지 않다. 상품 -> 카테고리 연관만 구현하면 된다./b>
  • 즉, 개념적으로 상품과 카테고리의 양방향 M:N 연관이 존재하지만 실제 구현에서는 상품 -> 카테고리의 단방향 M:N 연관만 적용하면 된다.
• RDBMS를 이용해 M:N 연관을 구현하려면 조인 테이블을 사용한다.

• JPA 를 이용하면 다음과 같은 매핑 설정을 사용해서 ID 참조를 이용한 M:N 단방향 연관을 구현할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13

@Entity
@Table(name = "product")
public class Product {
    @EmbeddedId
    private ProductId id;
    
    @ElementCollection
    @CollectionTable(name = "product_category", 
            joinColumns = @JoinColumn(name = "product_id))
    private Set<CategoryId> categoryIds;
    
    ...
}

• 이 매핑은 카테고리 ID 목록을 보관하기 위해 밸류 타입에 대한 컬렉션 매핑을 이용했다.
  • 이 매핑을 사용하면 아래 코드와 같이 JPQL의 member of 연산자를 이용해서 특정 Category에 속한 Product 목록을 구하는 기능을 구현할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

@Repository
public class JpaProductRepository implements ProductRepository {
    @PersistenceContext
    private EntityManager entityManager;

    @Override
    public List<Product> findByCategoryId(CategoryId categoryid, int page, int size) {
        TypedQuery<Product> query = entityManager.createQuery(
            "select p from Product p " + 
            "where :catId member of p.categoryIds order by p.id.id desc", Product.class);
        query.setParameter("catId", categoryId);
        query.setFirstResult((page - 1) * size);
        query.setMaxResults(size);
        return query.getResultList();
    }
}

애그리거트를 팩토리로 사용하기

• 예를 들어, 특정 상점에서 더 이상 상품을 등록을 할 수 없도록 차단된 상태라고 할 때 상품 등록 기능을 아래와 같이 응용 서비스 로직에 구현할 수 있을 것이다. (예제 코드에 오타가 있는 듯하여 임의로 수정했다.)

1
2
3
4
5
6
7
8
9
10
11
12
13

public class RegisterProductService {
    public ProductId registerNewProduct(NewProductRequest req) {
        Store store = accountRepository.findStoreById(req.getStoreId());
        checkNull(store);
        if (store.isBlocked()) {
          throw new StoreBlockedException();
        }
        ProductId id = productRepository.nextId();
        Product product = accout.createProduct(id, store.getId(), ...);
        productRepository.save(product);
        return id;
    }
} 

• 코드가 나빠조이진 않지만 중요한 도메인 로직 처리가 응용 서비스에 노출되었다.
  • Store가 Product 를 생성할 수 있는지 여부를 판단하고 Product를 생성하는 것은 논리적으로 하나의 도메인 기능인데 이 도메인 기능을 응용 서비스에서 구현하고 있는 것이다.
• 이 도메인 기능을 넣기 위한 별도의 도메인서비스나 팩토리 클래스를 만들수도 있지만 이 기능을 구현하기에 더 좋은 장소는 Store 애그리거트이다.
  • Product를 생성하는 기능을 Store 애그리거트에 다음과 같이 옮겨보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

public class Store extends Member {
    public Product createProduct(ProductId newProductId, /*...*/) {
        if (isBlocked()) throw new StoreBlockedException();
        return new Product(newProductId, getId(), /*...*/);
    }
}

public class RegisterProductService {
    public ProductId registerNewProduct(NewProductRequest req) {
        Store account = accountRepository.findStoreById(req.getStoreId());
        checkNull(account);
        ProductId id = productRepository.nextId();
        Product product = accout.createProduct(id, /*...*/);
        productRepository.save(product);
        return id;
    }
}

• Store 애그리거트의 createProduct() 는 Product 애그리거트를 생성하는 패고틸 역할을 한다.
• 앞선 코드와 차이점이라면 응용 서비스에서 더 이상 Store의 상태를 확인하지 않는 다는 것이다.
• 이렇게 함으로써 도메인 응집도도 높아지게 된다.

밸류 컬렉션을 @Entity로 매핑하기

Reference

• 예제 코드 및 이미지
  • https://minkukjo.github.io/tag/development-ddd/
  • https://velog.io/@freesky/DDD-Start-%EC%95%A0%EA%B7%B8%EB%A6%AC%EA%B1%B0%ED%8A%B8

Chapter4-리포지터리와 모델구현(JPA 중심)

JPA를 이용한 리포지토리 기능 구현

모듈 구현

• 2장에서 언급한 것처럼 리포지토리 인터페이스는 애그리거트와 같이 도메인 영역에 속하고, 리포지터리를 구현한 클래스는 인프라스트럭처 영역에 속한다.

팀 표준에 따라 리포지터리 구현 클래스를 domain.impl과 같은 패키지에 위치시키는 경우도 있다. 이는 리포지터리 인터페이스와 구현체를 분리하기 위한 타협안 같은 것이지 좋은 설계 원칙을 따르는 것은 아니다. 가능하면 리포지터리 구현 클래스를 인프라스트럭처 영역에 위치시켜서 인프라스트럭처에 대한 의존을 낮춰야 한다.

리포지터리 기본 기능 구현

삭제 기능: 삭제 요구사항이 있더라도 여러 이유로 데이터를 실제로 삭제하는 경우는 많지 않다. 관리자 기능에서 삭제한 데이터까지 조회해야 하는 경우도 있고 데이터 원복을 위해 일정 기간 동안 보관해야 할 때도 있기 때문이다. 이런 이유로 사용자가 삭제 기능을 실행시 데이터를 바로 삭제하기 보단 삭제 플래그를 사용해서 화면에 보여줄지 여부를 결정하는 방식으로 구현한다.

매핑 구현

엔티티와 밸류 기본 매핑 구현

1
2
3
4
5
6
7
8
9
10
11

@Embeddable
public class Orderer {
	// MemberId에 정의된 칼럼 이름을 변경하기 위해
  // @AttributeOverride 애노테이션 사용
  @Embedded
  @AttributeOverrides(@AttributeOverride(name = "id", column = @Column(name = "orderer_id")))
  private MemberId memberId;
  
  @Column(name = "orderer_name")
  private String name;
}

• @AttributeOverrides 어노테이션을 이용해서 매핑할 칼럼 이름을 변경한다.

기본 생성자

• JPA의 @Entity 와 @Embeddable 로 클래스를 매핑하려면 기본 생성자를 제공해야 한다.
• 하이버네이트와 같은 JPA 프로바이더는 DB에서 데이터를 읽어와 매핑된 객체를 생성시 기본 생성자를 사용해서 객체를 생성한다.
  • 이런 기술적 제약으로 Receiver와 같은 불변 타입은 기본 생성자가 필요 없음에도 불구하고 다음과 같이 기본 생성자를 추가해야 한다.
  • 이때 다른 코드에서 기본 생성자를 사용하지 못하도록 protected 로 선언하는 것이 좋다.

1
2
3
4

@Embeddable
public class Receiver {
  protected Receiver() {} 
}

Note: 하이버네이트는 클래스를 상속한 프록시 객체를 이용해서 지연 로딩을 구현한다. 이 경우 프록시 클래스에서 상위 클래스의 기본 생성자를 호출할 수 있어야 하므로 지연 로딩 대상이 되는 @Entity 와 @Embeddable의 기본 생성자는 private 이 아닌 protected로 지정해야 한다.

필드 접근 방식 사용

• JPA는 필드와 메서드(get/set)의 두 가지 방식으로 매핑을 처리할 수 있다.
• 엔티티를 객체가 제공할 기능 중심으로 구현하도록 유도하려면 JPA 매핑 처리를 프로퍼티 방식이 아닌 필드 방식으로 선택해서 불필요한 get/set/ 메서드를 구현하지 말아야 한다.

1
2
3
4
5
6
7
8
9

@Entity
// @Access(AccessType.PROPERTY)
@Access(AccessType.FIELD)
public class Order {
  @EmbeddableId
  private OrderNo number;
  
  ...
}

Note: JPA 구현체인 하이버네이트는 @Access를 이용해 명시적으로 접근 방식을 지정하지 않으면 @Id나 @EmbeddId가 어디에 위치했느냐에 따라 접근 방식을 결정한다. 즉, 필드에 위치하면 필드 접근 방식을, get 메서드에 위치하면 메서드 접근 방식을 선택한다.

AttributeConverter를 이용한 밸류 매핑 처리

• JPA 2.0 버전에선 두 개 이상의 프로퍼티를 가진 밸류 타입을 한개 DB칼럼에 매핑하기 위해 칼럼과 매핑하기 위한 프로퍼티를 따로 추가하고 get/set 메서드에서 실제 밸류 타입과 변환 처리를 해야 했다.

1
2
3
4
5
6
7
8
9
10
11
12

public class Product {
  @Column(name = "WIDTH")
  private String width;

  public Length getWidth() {
    return new Length(width); // DB 칼럼 값을 실제 프로퍼티 타입으로 변환
  }

  void setWidth(Length width) {
    this.width = width.toString(); // 실제 프로퍼티 타입을 DB 칼럼 값으로 변환
  }
}

• JPA 2.1에선 AttributeConverter를 사용해서 밸류 타입과 칼럼 데이터 간의 변화 처리를 위한 기능을 사용할 수 있다.
• autoApply가 true일 경우, 모델에 출현하는 모든 Money 타입의 프로퍼티에 대해 MoneyConverter를 자동으로 적용한다.
  • false 인 경우 프로퍼티 값을 변환할 때 사용할 컨버터를 직접 지정할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

public interface AttributeConverter<X, Y> {
    Y convertToDatabaseColumn(X var1);

    X convertToEntityAttribute(Y var1);
}

// autoApply가 true일 경우, 모델에 출현하는 모든 Money 타입의 프로퍼티에 대해 MoneyConverter를 자동으로 적용한다.
// false인 경우, 프로퍼티 값을 변환할 때 사용할 컨버터를 직접 지정할 수 있다.
@Converter(autoApply = true)
public class MoneyConverter implements AttributeConverter<Money, Integer> {
  @Override
  public Integer convertToDatabaseColumn(Money money) {
    if (money == null) {
      return null;
    } else {
      return money.getValue();
    }
  }
  
  @Override
  public Money convertToEntityAttribute(Integer value) {
    if (value == null) return null;
    else return new Money(value);
  }
}

public class Order {
  ...

  @Column(name = "total_amounts")
  @Convert(converter = MoneyConverter.class)
  private Money toalAmounts;
}

밸류 컬렉션: 별도 테이블 매핑

• 밸류 타입 컬렉션은 별도 테이블에 보관한다.

• 밸류 컬렉션을 저장하는 ORDER_LINE 테이블은 외부키를 이용해서 엔티티에 해당하는 PURCHASE_ORDER 테이블을 참조한다.
• 이 외부키는 컬렉션이 속할 엔티티를 의미한다.
• List 타입의 컬렉션은 인덱스 값이 필요하므로 ORDER_LINE 테이블엔 인덱스 값을 저장하기 위한 칼럼(line_idx)도 존재한다.
• 밸류 컬렉션을 별도 테이블로 매핑할 땐 @ElementCollection과 @CollectionTable 을 함께 사용한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@Entity
@Table(name = "purchase_order")
public class Order {
  ...
  @ElementCollection
  @CollectionTable(name = "order_line", joinColumns = @JoinColumn(name = "order_number"))
  @OrderColumn(name = "line_idx")
  private List<OrderLine> orderLines;
  ...
}

@Embeddable
public class OrderLine {
  @Embedded
  private ProductId productId;
  
  @Column(name = "price")
  private Money price;
  
  ...  
}

• @OrderColumn 어노테이션으로 지정한 칼럼에 리스트의 인덱스 값을 지정한다.
• @CollectionTable 은 밸류를 저장할 테이블을 지정할 때 사용한다.

밸류 컬렉션: 한 개 칼럼 매핑

• 밸류 컬렉션을 별도 테이블이 아닌 한 개 칼럼에 저장해야 할 때가 있다.
• AttributeConverter 를 사용하면 쉽게 해결할 수 있는데 밸류 컬렉션을 표현하는 새로운 밸류 타입을 추가해야 한다.(일급 컬렉션)

1
2
3
4
5
6
7
8
9
10
11
12

public class EmailSet {
  private Set<Email> emails = new HashSet<>();
  
  private EmailSet(){}
  private EmailSet(Set<Email> emails) {
    this.emails.addAll(emails);
  }
  
  public Set<Email> getEmails() {
    return Collections.unmodifiableSet(emails);
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@Converter
public class EmailSetConverter implements AttributeConverter<EmailSet, String> {
  @Override
  public String convertToDatabaseColumn(EmailSet attribute) {
    if (attribute == null) return null;
    return attribute.getEmails().stream()
      .map(Email::toString)
      .collect(Collectors.joining(","));
  }
  
  @Override
  public EmailSet convertToEntityAttribute(String dbData) {
    if (dbData == null) return null;
    String emails = dbData.split(",");
    Set<Email> emailSet = Arrays.stream(emails)
      .map(value -> new Email(value))
      .collect(toSet());
    return new EmailSet(emailSet);
  }
}

1
2
3

@Column(name = "emails")
@Convert(converter = EmailSetConverter.class)
private EmailSet emailSet;

밸류를 이용한 아이디 매핑

• 밸류 타입을 식별자로 매핑하면 @Id 대신 @EmbeddedId 어노테이션이 필요하다.
• JPA에서 식별자 타입은 Serializable 타입이어야 하므로 Serializable 인터페이스를 상속받아야 한다.
• 밸류 타입의 식별자를 구현할 때 얻을 수 있는 장점은 식별자에 기능을 추가할 수 있다. (is2ndGeneration 메서드 참조)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

@Entity
@Table(name = "purchase_order")
public class Order {
  @EmbeddedId
  private OrderNo orderId;
  ...
}

@Embeddable
public class OrderNo implements Serializable {
  @Column(name = "order_number")
  private String number;
  
  // 1세대 시스템의 주문 번호와 2세대 시스템의 주문 번호가 있다고 가정할 때 이를 구분하기 위한 메서드 구현
  public boolean is2ndGeneration() {
    return number.startWith("N");
  }
}

별도 테이블에 저장하는 밸류 매핑

• 애그리거트에 속한 객체가 밸류인지 엔티티인지 구분하는 방법은 고유 식별자를 갖는지 여부를 확인하는 것이다.
• 하지만, 식별자를 찾을 때 매핑되는 테이블의 식별자(PK)를 애그리거트 구성요소의 식별자와 동일한 것으로 착각해선 안된다.
• 별도 테이블로 저장되고 테이블에 PK가 있다 해서 테이블과 매핑되는 애그리거트 구성요소가 고유 식별자를 갖는 것은 아니다.

• 위 이미지에서 ARTICLE_CONTENT 테이블의 ID 칼럼이 식별자이므로 ARTICLE_CONTENT와 매핑되는 AriticleContent를 엔티티로 생각할 수 있는데, 이것 때문에 Article 과 ArticleContent를 두 엔티티 간의 일대일 연관으로 매핑하는 실수를 할 수 있다.
• ArticleContent를 엔티티로 생각할 수 있지만 ArticleContent 는 Article 의 내용을 담고 있는 밸류로 생각하는 것이 맞다.
  • ARTICLE_CONTENT의 ID 는 식별자이기는 하지만 이 식별자를 사용하는 이유는 ARTICLE 테이블의 데이터와 연결하기 위함이지 ARTICLE_CONTENT를 위한 별도 식별자가 필요하기 때문은 아니다.

• 이때 @SecondaryTable 과 @AttributeOverride를 사용하여 밸류를 매핑한 테이블을 지정한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

@Entity
@Table(name = "article")
@SecondaryTable(
	name = "article_content",
  pkJoinColumns = @PrimaryKeyJoinColumn(name = "id")
)
public class Article {
  @Id
  private Long id;
  
  @AttributeOverrides({
    @AttributeOverride(name = "content", column = @Column(table = "article_content")),
    @AttributeOverride(name = "contentType", column = @Column(table = "article_content"))
  })
  private ArticleContent content;

  ...
}

• @SecondaryTable의 name 속성은 밸류를 저장할 테이블을 지정한다.
  • pkJoinColumns 속성은 밸류 테이블에서 엔티티 테이블로 조인할 때 사용할 칼럼을 지정한다.
  • content 필드에 @AttributeOverride 를 사용하여 해당 밸류 데이터가 저장된 테이블 이름을 지정한다.
• @SecondaryTable을 이용하면 아래 코드를 실행할 때 두 테이블을 조인해서 데이터를 조회한다

1

Article article = entityManager.find(Article.class, 1L);

• 게시글 목록을 보여주는 화면은 article 테이블의 데이터만 필요하지, article_content 테이블의 데이터는 필요하지 않다.
• 그런데, @SecondaryTable 을 사용하면 목록 화면에 보여줄 Article을 조회할 때 article_content 테이블까지 조인해서 데이터를 읽어오게 되는 문제가 발생한다.
• 이 문제를 해결하기 위해 ArticleContent 를 엔티티로 매핑하고 이를 지연 로딩으로 설정하여 해결할 수도 있다. (둘 다 필요할때만 페치 조인으로 가져오는 방식으로)
• 하지만 이 방식은 엔티티가 아닌 모델을 엔티티로 만드는 것이므로 좋은 방법은 아니다.
  • 대신 조회 전용 기능을 구현하는 방법을 사용하는 것이 좋다.
  • JPA에서 조회 전용 쿼리를 실행하는 방법은 5장에서 살펴본다.

밸류 컬렉션을 @Entity 로 매핑하기

• 개념적으로 밸류인데 구현 기술 한계나 팀 표준으로 @Entity를 사용해야 할 때가 있다.
  • 예를 들어, 이미지 업로드 방식에 따라 이미지 경로와 썸네일 이미지 제공 여부가 달라진다고 했을 때 아래와 같은 계층 구조로 설계할 수 있다.

• JPA는 @Embeddable 타입의 클래스 상속 매핑을 지원하지 않는다.
• 따라서 상속 구조를 갖는 밸류 타입을 사용하려면 @Embeddable 대신 @Entity 를 이용한 상속 매핑으로 처리해야 한다.
• Image는 엔티티가 아니라 밸류이므로 상태를 변경하는 기능은 추가하지 않는다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@Entity
@Inheritance(startegy = InheritanceType.SINGLE_TABLE)
@Descriminator(name = "image_type")
@Table(name = "image")
public abstract class Image {
  ...
  // 밸류 타입이므로 상태 변경 기능이 있어선 안된다
}

@Entity
@DiscriminatorValue("II")
public class InternalImage extends Image {
  ...
}

@Entity
@DiscrimnatorValue("EI")
public class ExternalImage extends Image {
  ...
}

• Image는 밸류이므로 독자적인 라이프사이클을 갖지 않고 Product에 완전히 의존한다.
• 따라서 cascade 속성을 이용해서 Product 를 저장시 함께 저장되고, Product 삭제시 함께 삭제되도록 설정한다.
• 리스트에서 Image 객체를 제거하면 DB에서 함께 삭제되도록 orphanRemoval 을 true로 설정한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@Entity
@Table(name = "product")
public class Product {
  ...

  @OneToMany(cascade = {CascadeType.PERSIST, CascadeType.REMOVE}, orphanRemoval = true)
  @JoinColumn(name = "product_id")
  @OrderColumn(name = "list_idx")
  private List<Image> images = new ArrayList<>();
  ...
  public void changeImages(List<Image> newImages) {
    images.clear();
    images.addAll(newImages);
  }
}

• 하이버네이트에선 위처럼 엔티티를 위한 컬렉션 객체(images)의 clear 메서드를 호출시 select 쿼리로 대상 엔티티를 로딩 후 각 개별 엔티티에 대해 delete 쿼리를 수행한다.
  • 변경 빈도가 낮으면 괜찮지만 빈도가 높으면 전체 서비스 성능에 문제가 될 수 도 있다.
• 하이버네이트는 위와 반대로 @Embeddable 타입에 대한 컬렉션의 clear() 메서드를 호출하면 컬렉션에 속한 객체를 로딩하지 않고 한 번의 delete 쿼리로 삭제 처리를 수행한다,,
  • 이 경우엔 타입에 따라 다른 기능을 구현하려면 다음과 같이 if-else를 써야 하는 단점이 발생한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

@Embeddable
public class Image {
  @Column(name = "image_type")
  private String imageType;
  @Column(name = "image_path")
  private String path;

  ...
  public boolean hasThumbnail() {
    // 성능을 위해 다형을 포기하고 if-else로 구현
    if (imageType.equals("II")) {
      return true;
    }

    return false;
  }
}

• 코드 유지보수와 성능의 두 가지 측면을 고려해서 구현방식을 적절히 선택해야 한다.

ID 참조와 조인 테이블을 이용한 단방향 M:N 매핑

• 앞서 3장에서 애그리거트 간 집합 연관은 성능상의 이유로 피해야 한다고 했다.
• 그럼에도 불구하고 필요하다면 ID 참조를 이용한 단방향 집합 연관을 적용해 볼 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12

@Entity
@Table(name = "product")
public class Product {
  @EmbeddedId
  private ProductId id;
    
  @ElementCollection 
  @CollectionTable(name = "product_category", joinColumns = @JoinColumn(name = "product_id"))
  private Set<CategoryId> categoryIds;

  ...
}

• ID 참조를 이용한 애그리거트 간 단방향 M:N 연관은 밸류 컬렉션 매핑과 동일한 방식으로 설정한 것을 알 수 있다.
• @ElementCollection 을 이용하기 때문에 Product 를 삭제할 때 매핑에 사용한 조인 테이블의 데이터도 함께 삭제된다.
• 애그리거트를 직접 참조하는 방식을 사용했다면 영속성 전파나 로딩 전략을 고민해야 하는데 ID 참조방식을 사용함으로써 이런 고민을 할 필요가 사라지게 된다.

애그리거트 로딩 전략

• JPA 매핑을 설정할 때 항상 기억해야 할 점은 애그리거트에 속한 객체가 모두 모여야 완전한 하나가 된다는 것이다.
• 즉, 다음과 같이 애그리거트 루트를 로딩시 루트에 속한 모든 객체가 완전한 상태여야 함을 의미한다.

1
2

// product 는 완전한 하나여야 한다.
Prodcut product = productRepository.findById(id);

• 엔티티에 대한 매핑의 fetch 속성을 즉시 로딩(FetchType,EAGER)로 설정하면 find() 메서드로 애그리거트 루트를 구할 때 연관된 구성요소를 DB에서 함께 읽어온다.
• 하지만 컬렉션에 대해 로딩 전략을 EAGER 로 설정시엔 오히려 즉시 로딩 방식이 문제가 될 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

@Entity
public class Product {
  ...
  @OneToMany(
    cascade = {CascadeType.PERSIST, CascadeType.REMOVE},
    orphanRemoval = true,
    fetch = FetchType.Eager)
  @JoineColumn(name = "product_id")
  @OrderColumn(name = "list_idx")
  private List<Image> images = new ArrayList<>();

  @ElementCollection(fetch = FetchType.EAGER)
  @CollectionTable(name = "product_option", joinColumns = @JoinColumn(name = "product_id"))
  @OrderColumn(name = "list_idx")
  private List<Option> options = new ArrayList<>();
  
  ...
}

• 위와 같이 images 와 options 모두 EAGER 로 지정되어있을때 카타시안 조인을 사용해 불러오는데 이는 쿼리 결과에 중복을 발생한다.
  • Proudct의 image 가 2개이고 option이 2개이면 쿼리 결과로 구해지는 행 개수는 4개일 것이다.
  • 만약 데이터가 많다고하면 성능 문제가 될 수도 있다.
• 애그리거트는 개념적으로 하나여야 하지만, 루트 엔티티를 로딩하는 시점에 애그리거트에 속한 객체를 모두 로딩해야 하는 것은 아니다.
• 애그리거트가 완전해야 하는 이유는 두 가지다.
  • 1)상태를 변경하는 기능 실행시 애그리거트 상태가 완전해야 하기 때문에
  • 2)표현 영역에서 애그리거트의 상태 정보를 보여줄 때 필요하기 때문에
• 두 번째 이유는 별도의 조회 전용 기능을 구현하는 방식을 사용하는 것이 유리할 때가 많기에 애그리거트의 완전한 로딩과 관련된 문제는 상태 변경과 더 관련이 있다.
• 하지만 상태 변경 기능을 실행하기 위해 조회 시점에 즉시 로딩을 이용해서 애그리거트를 완전한 상태로 로딩할 필욘 없다.
• JPA는 트랜잭션 범위 내에서 지연 로딩을 허용하기 때문에 다음 코드처럼 실제로 상태를 변경하는 시점에 필요한 구성요소만 로딩해도 문제가 되지 않는다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

@Transactional
public void removeOptions(ProductId id, int optIdxToBeDeleted) {
  // Product 를 로딩. 컬렉션은 지연 로딩으로 설정했다면, Option은 로딩하지 않음
  Prodcut product = productRepository.findById(id);
  // 트랜잭션 범위이므로 지연 로딩으로 설정한 연관 로딩 가능
  product.removeOption(optIdxToBeDeleted);
}

@Entity
public class Product {
  @ElementCollection(fetch = FetchType.LAZY)
  @CollectionTable(name = "product_option", joinColumns = @JoinColumn(name = "product_id"))
  @OrderColumn(name = "list_idx")
  private List<Option> options = new ArrayList<>();
  
  public void removeOption(int optIdx) {
    // 실제 컬렉션에 접근할 때 로딩
    this.options.remove(optIdx);
  }
}

• 상태를 변경하는 기능을 실행하는 빈도보다 조회하는 기능을 실행하는 빈도가 훨씬 높다.
  • 그러므로 상태 변경을 위해 지연 로딩을 사용할 때 발생하는 추가 쿼리로 인한 실행 속도 저하는 문제 되지 않는다.
• 위와 같은 이유로 애그리거트 내의 모든 연관을 즉시 로딩으로 설정할 필욘 없다. 애그리거트에 맞게 즉시 로딩과 지연 로딩을 적절히 선택해야 한다.

애그리거트의 영속성 전파

• 애그리거트를 저장하거나 삭제할땐 애그리거트에 속한 모든 객체를 함께 저장하거나, 함께 삭제해야 한다.
• @Embeddable 매핑 타입의 경우엔 함께 저장되고 삭제되므로 cascade 속성을 추가로 설정하지 않아도 된다.
• 반면에 @Entity 타입에 대한 매핑은 cascade 속성을 사용해서 저장과 삭제시 함께 처리되도록 설정해야 한다.
• @OneToOne, @OneToMany 는 cascade 속성의 기본값이 없으므로 다음 코드처럼 cascade 속성 값으로 CascadeType.PERSIST, CascadeType.REMOVE 를 설정해야 한다.

1
2
3
4
5

@OneToMany(cascade = {CascadeType.PERSIST, CascadeType.REMOVE},
          orphanRemoval = true)
@JoinColumn(name = "product_id")
@OrderColumn(name = "list_idx")
private List<Image> images = new ArrayList<>();

식별자 생성 기능

• 식별자는 아래 세 가지 방식 중 하나로 생성한다.
  • 1)사용자가 직접 생성
  • 2)도메인 로직으로 생성
  • 3)DB 를 이용한 일련번호 생성

1) 사용자가 직접 생성

• 식별자 생성주체가 사용자이므로 도메인 영역에 식별자 생성 기능을 구현할 필요 없다.

2) 도메인 로직으로 생성

• 별도 서비스로 식별자 생성 기능을 분리해야 한다.
• 식별자 생성 규칙은 도메인 규칙이므로 도메인 영역에 식별자 생성 기능을 위치시켜야 한다.

1
2
3
4
5
6
7
8
9
10
11
12
13

public class OrderIdService {
  public OrderId createId(UserId userId) {
    if (userId == null) {
      throw new IllegalArgumentException("invalid userid: " + userId);

      return new OrderId(userId.toString() + "-" + timestamp());
    }
  }

  private String timestamp() {
    return Long.toString(System.currentTimeMillis());
  }
}

• 또한 식별자 생성 규칙을 규현하기에 적합한 또 다른 위치는 리포지터리이다.

1
2
3
4
5

public interface ProductRepository {
  ...
  ProductId nexxtId();
  ...
}

3) DB 를 이용한 일련번호 생성

• JPA는 저장 시점에 생성한 식별자를 @Id로 매핑한 프로퍼티/필드에 할당한다.
• 실제 저장(영속화)된 후에 할당된 식별자를 사용할 수 있다.

Reference

• 예제 코드 및 이미지
  • https://heeveloper.github.io/2020/07/18/04-%EB%A6%AC%ED%8F%AC%EC%A7%80%ED%84%B0%EC%99%80-%EB%AA%A8%EB%8D%B8-%EA%B5%AC%ED%98%84/

Chapter5-스프링 데이터 JPA를 이용한 조회기능

시작에 앞서

• CQRS 는 명령(COMMAND) 모델과 조회(Query) 모델을 분리하는 패턴이다.
  • 명령 모델은 상태(데이터)를 변경하는 기능을 구현할 때 사용된다(ex. 회원 가입, 암호 변경, 주문 취소)
  • 조회 모델은 데이터를 조회하는 기능을 구현시 사용된다.(ex. 주문 목록, 주문 상세)
• 주문 취소, 배송지 변경 기능을 포함하여 앞에서 살펴본 것 처럼 도메인 모델은 명령 모델로 주로 사용된다.
• 반면에, 이 장에서 설명할 정렬, 페이징, 검색 조건 지정과 같은 기능은 주문 목록, 상품 상세와 같은 조회기능에서 사용된다. 즉 이장에서 살펴볼 구현 방법은 조회 모델을 구현시 주로 사용한다.

Note: 모든 DB연동 코드를 JPA만 사용해서 구현해야 한다고 생각하진 말자. MyBatis, JdbcTemplate 등 다양한 기술을 사용해서 조회 모델을 구현할 수 있다.

검색을 위한 스펙

• 검색 조건이 고정되어 있다면 특정 조건으로 조회하는 기능을 만들면 되지만, 만약 검색 조건을 다양하게 조합해야 할 때 사용할 수 있는 것이 스펙(Specification)이다.
• 스펙은 애그리거트가 특정 조건을 충족하는지를 검사할 때 사용하는 인터페이스다.

1
2
3

public interface Specification<T> {
  boolean isSatisfiedBy(T agg);
}

• agg 파라미터는 검사 대상이 되는 객체이며 리포지터리에서 사용하면 애그리거트 루트가 되고 스펙을 DAO 에 사용하면 검색 결과로 리턴할 데이터 객체가 된다.
• isSatisfiedBy() 메서드는 검사 대상 객체가 조건을 충족하면 true를 리턴하고, 그렇지 않으면 false 를 리턴한다.
• 예를 들어, Order 애그리거트 객체가 특정 고객의 주문인지 확인하는 스펙은 다음과 같이 구현 가능하다.

1
2
3
4
5
6
7
8
9
10
11

public class OrdererSpec implements Specification<Order> {
  private String orderId;

  public OrdererSpec(String ordererId) {
    this.ordererId = ordererId;
  }

  public boolean isSatisfiedBy(Order agg) {
    return agg.getOrdererId().getMemberId().getId().equasl(orererId);
  }
}

• 리포지터리나 DAO는 검색 대상을 걸러내는 용도로 스펙을 사용한다.
• 만약 리포지토리가 메모리에 모든 애그리거트를 보관하고 있다면 다음과 같이 스펙을 사용할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class MemberOrderRepository implements OrderRepository {
  public List<Order> findAll(Specification<Order> spec) {
    List<Order> allOrders = findAll();
    return allOrders.stream()
                    .filter(order -> spec.isSatisfiedBy(order))
                    .toList();
  }
  ...
}

// 검색 조건을 표현하는 스펙을 생성
SPecification<Order> ordererSpec = new OrdererSpec("madvirus");
// 리포지터리에 전달
List<Order> orders = orderRepository.findAll(ordererSpec);

• 하지만 실제 스펙은 이렇게 구현하지 않는다.
• 모든 애그리거트 객체를 메모리에 보관핟기도 어렵고 설사 메모리에 다 보관할 수 있다하더라도 조회 성능에 심각한 문제가 발생하기 때문이다.
• 실제 스펙은 사용하는 기술에 맞춰 구현하면 되는데 스프링 데이터 JPA를 이용한 스펙 구현에 대해 알아볼 것이다.

스프링 데이터 JPA를 이용한 스펙 구현

• 스프링 데이터 JPA 는 검색 조건을 표현하기 위한 인터페이스인 Specification 을 제공한다.

1
2
3
4
5
6
7
8

public interface Specification<T> extends Serializable {
  // not, where, and, or 메서드 생략

  @Nullable
  Predicate toPredicate(Root<T> root, 
                        CriteriaQuery query, 
                        CriteriaBuilder cb);
}

• 제네릭 타입 파라미터 T는 JPA엔티티 타입을 의미하며, toPredicate() 메서드는 JPA Criteria API에서 조건을 표현하는 Predicate 를 생성한다.
• 이를 활용한 예시는 아래와 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class OrdererIdSpec implements Specification<OrderSummary> {
  private String ordererId;

  public OrdererIdSpec(String ordererId) {
    this.ordererId = ordererId;
  }

  @Override
  public Predicate toPredicate(Root<T> root, 
                        CriteriaQuery query, 
                        CriteriaBuilder cb) {
    return cb.equals(root.get(OrderSummary_.ordererId), ordererId);
  }
}

• OrdererSummary 엔티티에 대한 검색 조건을 표현한다.
• ordererId 프로퍼티 값이 생성자로 전달받은 값과 동일한지 비교하는 Predicate 를 생성한다.
• 스펙 구현 클래스를 개별적으로 만들지 않고 별도 클래스에 스펙 생성 기능을 모아도 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

public class OrderSummarySpec {
  public static Specification<OrderSummary> ordererId(String ordererId) {
    return (Root<OrderSummary> root, CriteriaQuery<?> query, CriteriaBuilder cb) ->
      cb.equals(root.<String>get("ordererId"), ordererId);
  }

  public static Specification<OrderSummary> orderDateBetween(LocalDateTime from, LocalDateTime to) {
    return (Root<OrderSummary> root, CriteriaQuery<?> query, CriteriaBuilder cb) ->
      cb.equals(root.get(OrderSummary_.orderDate), from, to);
  }
}

// 스펙 생성이 필요한 코드는 스펙 생성 기능을 제공하는 클래스를 이용해서 조금 더 간결하게 스펙을 생성 가능하다.
Specification<OrderSummary> betweenSpec = OrderSummarySpecs.orderDateBetween(from, to);

JPA 정적 메타 모델

• 위 예제 코드에서 OrderSummary_.ordererId 로 사용되는 부분이 있는데, OrderSummary_ 클래스는 JPA정적 메타 모델을 정의한 코드이다.
• 정적 메타 모델 클래스는 다음과 같이 구현 가능하다.

1
2
3
4
5
6
7
8

@StaticMetamoidel(OrderSummary.class)
public class OrderSummary_ {
  public static volatile SingularAttribute<OrderSummary, String> number;
  public static volatile SingularAttribute<OrderSummary, Long> version;
  public static volatile SingularAttribute<OrderSummary, String> ordererId;
  public static volatile SingularAttribute<OrderSummary, String> ordererName;
  ... 생략
}

• 정적 메타 모델은 @StaticMetamodel 애너테이션을 이용해서 관련 모델을 지정한다.
• 메타 모델 클래스는 모델 클래스의 이름 뒤에 ‘_‘을 붙인 이름을 갖는다.
• 정적 메타 모델 클래스는 대상 모델의 각 프로퍼티와 동일한 이름을 갖는 정적 필드를 정의한다.
• 이 정적 필드는 프로퍼티에 대한 메타 모델로서 프로퍼티 타입에 따라 SingularAttribute, ListAttribute 등의 타입을 사용해서 메타 모델을 정의한다.
• 정적 메타 모델을 사용하는 대신 문자열로 프로퍼티를 지정할 수도 있다.

1

cb.equals(root.<String>get("ordererId"), ordererId);

• 하지만 문자열은 오타 가능성이 있고, 실행전까진 오타가 있다는 것을 놓치기 쉽다.
• 게다가 IDE의 코드 자동 완성 기능을 사용할 수 없어 입력할 코드도 많아진다.
• 이런 이유로 Criteria를 사용할땐 정적 메타 모델 클래스를 사용하는 것이 코드 안정성이나 생산성 측면에서 유리하다.
• 정적 메타 모델 클래스를 직접 작성할 수 있지만 하이버네이트와 같은 JPA 프로바이더는 정적 메타 모델을 생성하는 도구를 제공하고 있으므로 이들 도구를 사용하면 편리하다.

리포지터리/DAO에서 스펙 사용하기

• 스펙을 충족하는 엔티티를 검색하고 싶다면 findAll() 메서드를 사용하면 된다.
• 스프링 데이터 JPA 사용시 JpaSpecificationExecutor 를 상속받아서 사용 가능하다.

1
2
3
4
5
6
7

public interface JpaSpecificationExecutor<T> {
  // 생략...
  
  List<T> findAll(@Nullable Specification<T> spec);

  // 생략...
}

스펙 조합

• 스프링 데이터 JPA가 제공하는 스펙 인터페잇느느 스펙을 조합할 수 있는 두 메서드 and(), or() 를 제공하다.
  • and(): 두 스펙을 모두 충족하는 조건을 표현하는 스펙 생성
  • or(): 두 스펙 중 하나 이상 충족하는 조건을 표현하는 스펙을 생성

1
2
3
4
5
6
7
8
9
10

public interface Specification<T> extends Serializable {

  static <T> Specification<T> not(@Nullable Specification<T> spec) { ... }
  static <T> Specification<T> where(@Nullable Specification<T> spec) { ... }
  default Specification<T> and(@Nullable Specification<T> other) { ... }
  default Specification<T> or(@Nullable Specification<T> other) { ... }
  
  @Nullable
  Predicate toPredicate(Root<T> root, CriteriaQuery query, CriteriaBuilder cb); 
}

• 아래 코드는 spec1.and(spec2) 는 spec1 과 spec2 를 모두 충족하는 조건을 표현하는 spec3를 생성한다.

1
2
3
4
5

Specification<OrderSummary> spec1 = OrderSummarySpecs.ordererId("user1");
Specification<OrderSummary> spec2 = OrderSummarySpecs.orderDateBetween(LocalDateTime.of(2022, 1, 1, 0, 0, 0),
 LocalDateTime.of(2022, 1, 2, 0, 0, 0));

Specification<OrderSummary> spec3 = spec1.and(spec2);

• 아래와 같은 체이닝 기법으로 사용가능하여 불필요한 변수를 선언하지 않아도 된다.

1
2

Specification<OrderSummary> spec = OrderSummarySpecs.ordererId("user1")
.and(OrderSummarySpecs.orderDateBetween(from, to));

• not() 메서드는 정적 메서드로 조건을 반대로 적용할때 사용한다.

1

Specification<OrderSummary> spec1 = Specification.not(OrderSummarySpecs.ordererId("user1"));

• null 가능성이 있는 스펙 객체와 다른 스펙을 조합해야 할 때 Null 체크를 매번 하려면 다소 귀찮다.

1
2
3
4

Specification<OrderSummary> nullableSpec = createNullableSpec(); // null일 수 있음
Specification<OrderSummary> oterSpec = createOtherSpec();

Specification<OrderSummary> spec = nullable == null ? otherSpec : nullableSpec.and(otherSpec);

• where() 메서드를 사용면 이런 귀찮음을 줄일 수 있다.
  • null을 전달하면 아무 조건도 생성하지 않는 스펙 객체를 리턴하고 null이 아니면 인자로 받은 스펙 객체를 그대로 리턴하다.

1

Specification<OrderSummary> spec = Specification.where(createNulalbleSpec()).and(createOtherSpec());

정렬 지정하기

• 스프링 데이터 JPA는 두 가지 방법을 사용해서 정렬을 지정 가능하다.

1) 메서드 이름에 OrderBy를 사용해서 정렬 기준 지정

1
2
3
4
5

public interface OrderSummaryRepository extends JpaRepository<OrderSummary, Integer> {
  
  // 메서드 이름
  List<OrderSummary> findAllByOrderByOrderDateDescNumberAsc(String ordererId); // OrderDate 프로퍼티 기준으로 내림차순 정렬 후 Number 프로퍼티 기준으로 오름차순으로 정렬
}

• 위 방법의 단점은 정렬 조건이 많아질수록 메서드명이 길어진다는 것과 메서드 일므으로 정렬 순서가 정해지기 때문에 상황에 따라 정렬순서를 변경할 수도 없다.
• 이땐 아래 Sort 타입을 사용하면 된다.

2) Sort를 인자로 전달

1
2
3
4
5

public interface OrderSummaryRepository extends JpaRepository<OrderSummary, Integer> {
   
  // Sort
  List<OrderSummary> findAllByOrdererId(String ordererId, Sort sort);
}

• Sort 객체를 생성해서 인자로 넘겨주면 스프링 데이터 JPA 내부적으로 알아서 정렬 쿼리를 적용한다.

1
2
3
4
5
6
7
8
9
10
11

Sort sort = Sort.by("number").ascending();
List<OrderSummary> results = orderSummaryDao.findByOrdererId("user1", sort);

// 두 개 이상의 정렬 순서를 지정하고 싶다면 Sort#and() 메서드를 사용해서 두 sort 객체를 연결하면 된다.
Sort sort1 = Sort.by("number").ascending();
Sort sort2 = Sort.by("orderDate").descending();

Sort sort sort1.and(sort2);

// 메서드 체이닝도 가능하다.
Sort sort = Sort.by("number").ascending().and(Sort.by("orderDate").descending());

페이징 처리하기

• 스프링 데이터 JPA 는 페이징 처리를 위해 Pageable 인터페이스 타입을 이용한다.
• Sort 타입과 마찬가지로 find 메서드에 Pageable 타입 파라미터를 사용하면 페이징을 자동으로 처리해준다.

1
2
3
4
5
6
7
8

public interface OrderSummaryRepository extends JpaRepository<OrderSummary, Integer> {
  
  List<OrderSummary> findByOrderByNumberDesc(String ordererId, Pagable pagable);

  // 목록뿐 아니라 조건에 해당하는 전체 개수 및 페이징 처리에 필요한 데이터도 함께 제공
  Page<OrderSummary> findByOrderByNumberDesc(String ordererId, Pagable pagable);
  
}

• 이를 실제 호출할땐 Pageable 의 구현체인 PageRequest 객체를 생성해야 한다.

1
2

PageRequest pageReq = PageRequest.of(1, 10); // 페이지 번호, 한 페이지의 개수 (페이지 번호는 0부터 시작)
List<MemberData> user = memberDataDao.findbyNameLike("사용자%", pageReq);

• PageRequest 와 Sort 를 사용하면 정렬 순서도 지정가능하다.

1
2
3

Sort sort = Sort.by("name").descending();
PageRequest pageReq = PageRequest.of(1, 2, sort);
List<MemberData> user = memberDataDao.findbyNameLike("사용자%", pageReq);

• Pageable 을 사용하는 메서드의 리턴타입이 Page 일 경우 스프링 데이터 JPA는 목록 조회 쿼리와 함께 COUNT 쿼리도 실행해서 조건에 해당하는 데이터 갯수를 구한다.
• Page 는 전체 개수, 페이지 개수 등 페이징 처리에 필요한 데이터도 함께 제공한다.
• 다음은 Page 가 제공하는 메서드의 일부를 보여준다.

1
2
3
4
5
6
7
8
9

PageRequest pageReq = PageRequest.of(2, 3);
Page<MemberData> user = memberDataDao.findbyBlocked(false, pageReq);

List<MemberData> content = page.getContent(); // 조회 결과 목록
long totalElements = page.getTotalElements(); // 조건에 해당하는 전체 개수
int totalPages = page.getTotalPages(); // 전체 페이지 번호
int number = page.getNumber(); // 현재 페이지 번호
int numberOfElements = page.getNumberOfElements(); // 조회 결과 개수
int size = page.getSize(); // 페이지 크기

• 스펙을 사용하는 findAll() 메서드도 Pageable 을 사용할 수 있다.

1
2
3

public interface MemberDataDao extends Repository<MemberData, String> {
  Page<MemberData> findAll(Specification<MemberData> spec, Pageable pageable);
}

Note: 프로퍼티를 비교하는 findBy프로퍼티 형식의 메서드는 Pageable 타입을 사용하더라도 리턴타입이 List 면 COUNT 쿼리를 실행하지 않는다. 반면 스펙을 사용한 findAll 메서드에 Pageable 타입을 사용하면 리턴타입이 Page 가 아니어도 COUNT 쿼리를 실행한다. 만약 스펙을 사용하고 페이징 처리를 하면서 COUNT 쿼리는 실행하고 싶지 않다면 스프링 데이터 JPA가 제공하는 커스텀 리포지터리 기능을 이용해서 직접 구현해야 한다. 구현 방법이 궁금하면 https://javacan.tistory.com/entry/spring-data-jpa-range-query 문서를 참고하면 좋다.

• 쳐음부터 N개의 데이터가 필요하다면 Pageable 을 사용하지 않고 findFirstN형식의 메서드를 사용할 수도 있다.
• 예를 들어 다음 메서드는 name 프로퍼티 기준으로 like 검색한 결과를 name 프로퍼티 기준으로 오름차순 정렬해서 처음 3개를 조회한다. First 대신 Top을 사용해도 된다.
  • 만약 First나 Top 뒤에 숫자가 없으면 한 개 결과만 리턴한다.

1
2
3
4

List<MemberData> findFirst3ByNameLikeOrderByName(String name);
List<MemberData> findTop3ByNameLikeOrderByName(String name);

MemberData findFirstByBlockedOrderById(boolean blocked);

스펙 조합을 위한 스펙 빌더 클래스

• 스펙을 생성하다보면 다음 코드처럼 조건에 따라 스펙을 조합해야 할 때가 있다.

1
2
3
4
5
6
7
8
9
10
11

Specification<MemberData> spec = Specification.where(null);

if (searchReq.isOnleyNotBlocked()) {
  spec = spec.and(MemberDataSpecs.nonBlocked());
}

if (StringUtils.hasText(searchRequest.getName())) {
  spec = spec.and(MemberDataSpecs.nameLike(searchRequest.getName()));
}

List<MemberData> results = memberDataDao.findAll(Spec, PageRequest.of(0, 5));

• 위 코드는 if와 각 스펙을 조합하는 코드가 섞여 있어 실수하기 좋고 복잡한 구조를 갖는다.
• 이 점을 보완하기 위해 필자는 스펙 빌더를 만들어 사용한다.

1
2
3
4
5
6
7
8

Specification<MemberData> spec = SpecBuilder.builder(MemberData.class)
        .ifTrue(searchRequest.isOnlyNotBlocked(),
        () -> MemberDataSpecs.nonBlocked())
        .ifHasText(searchReq.getName(),
        name -> MemberDataSpecs.nameLike(searchReq.getName()))
        .toSpec();

List<MemberData> result = memberDataDao.findAll(spec, PageRequest.of(0, 5));

• if 블록을 사용할 때와 비교하면 코드양은 비슷하지만 메서드를 사용해서 조건을 표현하고 메서드 호출 체인으로 연속된 변수할당을 줄여 코드 가독성을 높이고 구조가 단순해진다.
• 스펙 빌더 코드는 아래와 같다. and(), ifHasText(), ifTrue() 메서드 외에는 직접 추가해서 사용하면 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

public class SpecBuilder {
    public static <T> Builder<T> builder(Class<T> type) {
        return new Builder<T>();
    }

    public static class Builder<T> {
        private List<Specification<T>> specs = new ArrayList<>();

        private void addSpec(Specification<T> spec) {
            if (spec != null) {
                specs.add(spec);
            }
        }

        public Builder<T> and(Specification<T> spec) {
            addSpec(spec);
            return this;
        }

        public Builder<T> ifHasText(String str,
                                    Function<String, Specification<T>> specSupplier) {
            if (StringUtils.hasText(str)) {
                addSpec(specSupplier.apply(str));
            }
            return this;
        }

        public Builder<T> ifTrue(Boolean cond,
                                 Supplier<Specification<T>> specSupplier) {
            if (cond != null && cond.booleanValue()) {
                addSpec(specSupplier.get());
            }
            return this;
        }

        public <V> Builder<T> ifNotNull(V value,
                                        Function<V, Specification<T>> specSupplier) {
            if (value != null) {
                addSpec(specSupplier.apply(value));
            }
            return this;
        }

        public Specification<T> toSpec() {
            Specification<T> spec = Specification.where(null);
            for (Specification<T> s : specs) {
                spec = spec.and(s);
            }
            return spec;
        }
    }
}