[독후감] 도메인 주도 개발 시작하기 [챕터 01, 02] (2)

독후감

[독후감] 도메인 주도 개발 시작하기 [챕터 01, 02] (2)

Choony 2023. 9. 22. 23:24

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

앞선 글에서 도메인 영역은 도메인의 핵심 모델을 구현한다고 하였다.

도메인 영역의 모델은 도메인의 주요 개념을 표현하며 핵심 로직을 구현한다. 1장에서 나왔던 엔티티와 밸류 타입은 도메인 영역의 주요 구성 요소이다. 이 두 요소와 함께 도메인 영역을 구성하는 요소를 아래의 표와 함께 살펴보자.

요소	설명
엔티티 ENTITY	고유의 식별자를 갖는 객체로 자신의 라이프 사이클을 갖는다. 주문, 회원, 상품과 같이 도메인의 고유한 개념을 표현한다. 도메인 모델의 데이터를 포함하며 해당 데이터와 관련된 기능을 함께 제공한다.
밸류 VALUE	고유의 식별자를 갖지 않는 객체로 주로 개념적으로 하나인 값을 표현할 때 사용된다. 배송지 주소를 표현하기 위한 주소나 구매 금액을 위한 금액와 같은 타입이 밸류 타입이다. 엔티티의 속성으로 사용할 뿐만 아니라 다른 밸류 타입의 속성으로도 사용할 수 있다.
애그리거트 AGGREGATE	애그리거트는 연관된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것이다. 예를 들어 주문과 관련된 Order 엔티티, OrderLine 엔티티, Orderer 밸류 객체를 '주문' 애그리거트로 묶을 수 있다.
리포지터리 REPOSITORY	도메인 모델의 영속성을 처리한다. 예를 들어 DBMS 테이블에서 엔티티 객체를 로딩하거나 저장하는 기능을 제공한다.
도메인 서비스 DOMAIN SERVICE	특정 엔티티에 속하지 않은 도메인 로직을 제공한다. '할인 금액 계산'은 상품, 쿠폰, 회원 등급, 구매 금액 등 다양한 조건을 이용해서 구현하게 되는데, 이렇게 도메인 로직에 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.

엔티티와 밸류

DB 테이블의 엔티티와 도메인 모델의 엔티티를 거의 같은 것이라 생각할 수 있는데 이는 점점 경험이 쌓이면 같은 것이 아니라는 것을 알게 될 것이다.

이 두 모델의 가장 큰 차이점은 도메인 모델의 엔티티는 데이터와 함께 도메인 기능을 함께 제공한다는 것이다. 예를 들어 주문을 표현하는 엔티티는 주문과 관련된 데이터뿐만 아니라 배송지 주소 변경을 위한 기능을 함께 제공한다.

public class Order {
	//주문 도메인 모델의 데이터
    private OrderNo number;
    private Orderer orderer;
    private ShippingInfo shippingInfo;
    ...
    
    // 도메인 모델 엔티티는 도메인 기능도 함께 제공
    public void changeShippingInfo(ShippingInfo shippingInfo) {
    	...
    }
}

도메인 모델 엔티티는 단순히 데이터를 담고 있는 데이터 구조라기보다는 데이터와 함께 기능을 제공하는 객체이다. 도메인 관점에서 기능을 구현하고 기능 구현을 캡슐화해서 데이터가 임의로 변경되는 것을 막는다.

또 다른 차이점은 도메인 모델의 엔티티는 두 개 이상의 데이터가 개념적으로 하나인 경우 밸류 타입을 이용해서 표현할 수 있다는 것이다.

예시로 위의 코드에서 Orderer는 밸류 타입으로, 다음과 같이 주문자 이름과 이메일 데이터를 포함할 수 있다.

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

1장에서 밸류는 불변으로 구현할 것을 권장하였다. 이는 엔티티의 밸류 타입 데이터를 변경할 때는 객체 자체를 완전히 교체한다는 것을 의미한다. 예를 들어 배송지 정보를 변경하는 코드는 기존 객체의 값을 변경하지 않고 다음과 같이 새로운 객체를 필드에 할당한다.

public class Order {
    private ShippingInfo shippingInfo;    
    ...
    
    private void setShippinInfo(ShippinInfo newShippingInfo) {
    	if (newShippinInfo == null) throw new IllegalArgumentException();
        // 밸류 타입의 데이터를 변경할 때는 새로운 객체로 교환한다.
        this.shippingInfo = newShippingInfo;
    }
}

애그리거트

도메인이 커질수록 개발할 도메인 모델도 커지면서 많은 엔티티와 밸류가 출현한다. 이럴수록 모델은 점점 더 복잡해진다.

도메인 모델이 복잡해지면 개발자가 전체 구조가 아닌 한 개 엔티티와 밸류에만 집중하는 상황이 발생한다. 이때 상위 수준에서 모델을 관리하지 않고 개별 요소에만 초점을 맞추다 보면, 큰 수준에서 모델을 이해하지 못해 큰 틀에서 모델을 관리할 수 없는 상황에 빠질 수 있다.

도메인 모델에서 개별 객체뿐만 아니라 상위 수준에서 모델을 볼 수 있어야 전체 모델의 관계와 개별 모델을 이해하는 데 도움이 된다. 도메인 모델에서 전체 구조를 이해하는데 도움이 되는 것이 바로 애그리거트이다.

위의 그림처럼 관련된 객체를 애그리거트로 묶으면 복잡한 도메인 모델을 관리하는 데 도움이 된다.

애그리거트를 사용하면 개별 객체가 아닌 관련 객체를 묶어서 객체 군집 단위로 모델을 바라볼 수 있게 된다. 개별 객체 간의 관계가 아닌 애그리거트 간의 관계로 도메인 모델을 이해하고 구현하게 되며, 이를 통해 큰 틀에서 도메인 모델을 관리할 수 있다.

애그리거트는 군집에 속한 객체를 관리하는 루트 엔티티를 갖는다.

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

애그리거트의 루트 엔티티에 대한 내용은 아래의 글을 읽어보면서 더 확 와닿았다. 꼭 읽어보길 바란다!!

https://techblog.woowahan.com/10600/

리포지터리

도메인 객체를 지속적으로 사용하기 위해선 RDMBS이나 NoSQL과 같은 물리적인 저장소에 도메인 객체를 보관해야 한다. 이를 위한 도메인 모델이 리포지터리이다. 엔티티나 밸류가 요구사항에서 도출되는 도메인 모델이라면 리포지터리는 구현을 위한 도메인 모델이다.

리포지터리는 애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의한다.

예를 들어 주문 애그리거트를 위한 리포지터리는 다음과 같이 정의할 수 있다.

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

메서드를 살펴보면 대상을 찾고 저장하는 단위가 애그리거트 루트인 Order인 것을 확인할 수 있다. Order는 애그리거트에 속한 모든 객체를 포함하고 있으므로 결과적으로 애그리거트 단위로 저장하고 조회한다.

도메인 모델 관점에서 OrderRepository는 도메인 객체를 영속화하는 데 필요한 기능을 추상화한 것으로 고수준 모듈에 속한다.

기반 기술을 이용해서 OrderRepository를 구현한 클래스는 저수준 모듈로 인프라스트럭처 영역에 속한다. (아래 그림 참고)

응용 서비스는 의존 주입과 같은 방식을 사용해서 실제 리포지터리 구현 객체에 접근한다.

응용 서비스와 리포지터리는 밀접한 연관이 있다. 아래는 그 이유이다.

- 응용 서비스는 필요한 도메인 객체를 구하거나 저장할 때 리포지터리를 사용한다.

- 응용 서비스는 트랜잭션을 관리하는데, 트랜잭션 처리는 리포지터리 구현 기술의 영향을 받는다.

리포지터리를 사용하는 주체가 응용 서비스이기 때문에 리포지터리는 응용 서비스가 필요로 하는 메서드를 제공한다.

- 애그리거트를 저장하는 메서드

- 애그리거트 루트 식별자로 애그리거트를 조회하는 메서드

// 예시 코드
public interface SomeRepository {
    void save(Some some);
    Some findById(SomeId id);
}

요청 처리 흐름

응용서비스는 도메인 모델을 이용해서 기능을 구현한다. 기능 구현에 필요한 도메인 객체를 리포지터리에서 가져와 실행하거나 신규 도메인 객체를 생성해 리포지터리에 저장한다.

'예매하기'나 '예매 취소'와 같은 기능을 제공하는 응용 서비스는 트랜잭션 관리를 해줘야 물리 저장소에 올바르게 반영이 된다.

스프링에서는 @Transactional 애너테이션을 이용해 트랜잭션을 처리할 수 있을 것이다.

인프라스트럭처 개요

앞서 DIP를 배우며 인프라스트럭처 영역에 대한 의존을 지양하라고 말하였다. 하지만 무조건 인프라스트럭처에 대한 의존을 없앨 필요는 없다. 예를 들어 스프링을 사용할 때 응용 서비스는 트랜잭션 처리를 위해 스프링이 제공하는 @Transactional을 사용하는 것이 편리하며, 영속성 처리를 위해 JPA의 경우 @Entity나 @Table과 같은 JPA 전용 애너테이션을 도메인 모델 클래스에서 사용하는 것이 XML 매핑 설정을 이용하는 것보다 편리하다.

구현의 편리함은 DIP가 주는 다른 장점(변경의 유연함, 테스트 쉬움)만큼 중요하기 때문에 DIP의 장점을 해치지 않는 범위에서 응용 영역과 도메인 영역에서 구현 기술에 대한 의존을 가져가는 것이 나쁘지 않다고 생각한다.

인프라스트럭처 영역에 대한 의존을 완전히 갖지 않으려고 하는 것이 자칫 구현을 더 복잡하고 어렵게 만들 수 있다.

+) 개인적으로 왜 @Transactional이나 @Entity @Table이 인프라스트럭처 의존과 관련 있는 애너테이션인지 감이 안 잡혀서 좀 찾아보았다. (feat. chatGPT)

모듈 구성

영역별로 별도 패키지로 구성한 모듈 구조이다.

도메인이 크면 위의 그림과 같이 하위 도메인으로 나누고 각 하위 도메인마다 별도 패키지를 구성한다.

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

도메인이 복잡하면 도메인 모델과 도메인 서비스를 다음과 같이 별도 패키지에 위치시킬 수도 있다.

- com.myshop.order.domain.order : 애그리거트 위치

- com.myshop.order.domain.service : 도메인 서비스 위치

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

- com.myshop.order.application.product

- com.myshop.order.application.category

간단한 스프링부트 상에서 패키지 구조를 봐보자!

도메인서비스에 해당하는 DiscountCalculationService 클래스가 service 패키지에 속하는것을 볼 수 있다.

책의 저자는 한 패키지에 가능하면 10~15개 미만으로 타입 개수를 유지하려고 노력한다고 한다. 이 개수를 넘어가면 패키지를 분리하는 시도를 해보자.