[책]DDD START! #2. 아키텍처 개요

bien·2024년 8월 19일

DDD 책

DDD_START!

목록 보기

2/3

1. 네 개의 영역

전형적인 4개의 영역: 표현, 응용, 도메인, 인프라스트럭처

표현영역

HTTP 요청을 응용 영역이 필요로 하는 형식으로 변환해서 응용 영역에 전달, 응용 영역의 응답을 HTTP 응답으로 변환해서 전송.
스프링 MVC 프레임워크가 표현 영역을 위한 기술의 한 예시
웹 Application에서 표현 영역의 사용자는 웹 브라우저 이용자, 혹은 REST API를 호출하는 외부 시스템일 수 있다.

응용영역

시스템이 사용자에게 제공해야 할 기능을 구현
- ex) 주문 등록, 주문 취소, 상품 상세 조회
응용 영역은 기능을 구현하기 위해 도메인 영역의 도메인 모델을 사용한다.
- 직접 로직을 수행하기 보다는 도메인 모델에 로직 수행을 위임한다.

public class CancelOrderService {

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

도메인 영역

도메인의 핵심 로직을 구현
- ex) Order, OrderLine, ShippingInfo
- 배송지변경, 결제완료, 주문 총액 계산과 같은 핵심 로직을 도메인에서 구현

인프라 스트럭처

구현 기술에 대한 것을 다룬다.
- RDBMS 연동, 메시징 큐에 메시지 전송 및 수신 기능 구현, 몽고DB나 HBase를 사용해 디비 연동을 처리
- SMTP를 이용한 메일 발송 기능, HTTP 클라이언트를 이용해 REST API를 호출하는 것도 처리
논리적인 개념을 표현하기 보다는 실제 구현을 다룬다.

2. 계층 구조 아키텍처

계층 구조의 아키텍처 구성

상위 계층에서 하위 계층으로의 의존만 존재하고, 하위 계층은 상위 계층을 의존하지 않는다.

구현의 편리함을 위해 유연한 계층구조 적용

표현, 응용, 도메인 계층이 상세한 구현 기술을 다루는 인프라스트럭처 계층에 종속되는 구조
- 인프라스트럭처 의존은, '테스트 어려움'과 '기능 확장의 어려움'이라는 두 가지 문제를 발생시킨다.
  - 이 문제는 DIP를 적용해 해결할 수 있다.

의존성 문제 예시

인프라스트럭처 코드

Drools라는 룰 엔진을 이용해 로직을 수행하는 인프라스트럭처 영역의 코드
evalute()에 값을 주면 별도 파일로 작성한 규칙을 이용해 연산을 수행하는 코드.

public class DroolsRuleEngine {
	private KieContainer kContainer;
    
    public DroolsRuleEngine() {
    	KieServices ks = KieServices.Factory.get();
        KContainer = ks.getKieClasspathContainer();
    }
    
    public void evalute(String sessionName, List<?> facts) {
    	KieSession kSession = kContainer.newKieSession(sessionName);
        try {
        	facts.forEach(x -> kSession.insert(x));
            kSession.fireAllRules();
        } finally {
        	kSession.dispose();
        }
    }
}

응용영역 코드

인프라스트럭처 영역의 DroolsRuleEngine을 이용해 응용영역의 코드를 작성했다.
이 코드는 2개의 문제를 가진다.
1. CalculateDiscountService만 테스트하기 힘들다.
  - 해당 테스트는 RuleEngine이 완벽하게 작동할때만 가능하다.
2. 구현 방식을 변경하기 힘들다.
  - calculateDiscount()가 겉으로는 인프라 스트럭처의 기술에 의존하지 않는 것처럼 보여도, 해당 기술에 완전하게 의존하고 있다.
    - discountCalculation는 세션이름으로 인프라 스트럭처에서 변경된다면 함께 변경되어야 한다.
    - MutableMoney는 룰 적용 결과값을 보관하기 위해 추가한 타입으로, 다른 방식을 이용했다면 필요없는 타입이다.

public class CalculateDiscountService {
	private DroolsRuleEngine ruleEngine;
    
    public CalculateDiscountService() {
    	ruleEngine = new DroolsRuleEngine();
    }
    
    public Money calculateDiscount(OrderLine orderLine, String customerId) {
    	Customer customer = findCustomer(cutomerId);
        
        // Drolls에 특화된 코드: 연산 결과를 받기 위해 추가한 타입
        MutableMoney money = new MutableMoney(0);
        // Drools에 특화된 코드: 룰에 필요한 데이터(지식)
        List<?> facts = Arrays.asList(customer, money);
        facts.addAll(orderLines);
        // Drools에 특화된 코드: Drools의 세션 이름
        ruleENgine.evalue("discountCalculation", facts);
        return money.toImmutableMoney();
    }
    ...
}

3. DIP

고수준 모듈과 저수준 모듈

고수준 모듈: 의미 있는 단일 기능을 제공하는 모듈
저수준 모듈: 하위 기능을 실제로 구현한 것
고수준 모듈이 제대로 동작하려면 저수준 모듈을 사용해야 한다.
- 그러나, 이는 구현 변경과 테스트의 어려움을 야기한다.

DIP는 이 문제를 해결 하기 위해, 저수준 모듈이 고수준 모듈에 의존하도록 바꾼다.
- 이는 추상화한 인터페이스를 통해 가능하다.
  - 결과적으로, 고수준 모듈이 저수준 모듈을 사용해야 하는 현 상황에서, 저수준 모듈이 고수준 모듈을 의존하는 역전이 발생한다.

응용계층 코드: 추상화 적용

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

public class CalculateDiscountService {
	private RuleDiscounter ruleDiscounter;
    
    public CalculateDiscountService(RuleDiscounter ruleDiscounter) {
    	this.ruleDsicounter = ruleDiscounter;
    }
    
    public Money calculateDiscount(OrderLine orderLine, String customId) {
    	Customer customer = findCustomer(customId);
        return ruleDiscounter.applyRules(customer, orderLines);
    }
    ...
    
}

계산하는 로직을 인터페이스로 추상화했다.
- 응용 코드에서는 RuleDiscounter가 룰을 적용한다는 것만 알고있다.
- 실제 RuleDiscounter의 구현 객체는 생성자로 주입받는다.

인트라스트럭쳐 코드: 추상화 이용

public class DroolsRuleEngine {
	private KieContainer kContainer;
    
    public DroolsRuleEngine() {
    	KieServices ks = KieServices.Factory.get();
        KContainer = ks.getKieClasspathContainer();
    }
    
    @Override
    public Money calculateDiscount(Customer customer, List<OrderLine> orderLines) {
    	KieSession kSession = kContainer.newKieSession(sessionName);
        try {
        	facts.forEach(x -> kSession.insert(x));
            kSession.fireAllRules();
        } finally {
        	kSession.dispose();
        }
        return money.toImmutableMoney();
    }
}

DIP (Dependency Inversion Principle, 의존 역전 원칙)
- 고수준 모듈이 저수준 모듈을 사용하기 위해 의존이 필요한데, 반대로 저수준 모듈이 고수준 모듈에 의존한다고 해서 이를 의존 역전 원칙이라고 부른다.
- DIP를 적용하면 앞서 발생한 구현 교체와 테스트의 어려움이 해소된다.

DIP 주의사항

단순히 인터페이스와 구현 클래스를 분리하는 것이 아니라, 고수준 모듈이 저수준 모듈에 의존하지 않도록 하는 것이 핵심이다.
- 이를 위해서, 하위 기능을 추상화한 인터페이스는 고수준 모듈 관점에서 도출해야 한다.
- 예시에서는 할인 금액 계산이 그것이다.

DIP와 아키텍처

아키텍처 수준에서 DIP를 적용하면 인프라 영역이 응용 영역과 도메인 영역에 의존하는 구조가 된다.
- 이 경우, 도메인과 응용 영역에 대한 영향을 최소화하며 구현 기술을 변경하는 것이 가능해진다.

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

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

엔티티와 밸류

엔티티에는 2가지 종류가 있다; 도메인 모델 vs DB 관계형 모델
- 차이점) 도메인 모델의 엔티티는 데이터와 함께 도메인 기능을 함께 제공

도메인 모델의 엔티티
- 차이점1) 단순히 데이터를 담고있는 데이터 구조라기보다는, 데이터와 함께 기능을 제공하는 객체이다.
  - 도메인 관점에서 기능을 구현하고, 기능 구현을 캡슐화해서 데이터가 임의로 변경되는 것을 막는다.
- 차이점2) 도메인 모델의 엔티티는 두 개 이상의 데이터가 개념적으로 하나인 경우 밸류 타입을 이용해 표현할 수 있다.

차이점1. 데이터와 함께 기능을 제공

예를 들어, 주문(Order) 엔티티는, 주문과 관련된 데이터 뿐만 아니라 배송지 주소 변경을 위한 기능을 함께 제공한다.

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

}

차이점2. 벨류 타입을 이용해 표현

주문자의 이름과 이메일을 포함하는 주문자(Orderer)는 벨류 타입을 이용해 표현 가능하다.

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

밸류; 불변 구현

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

public class Order {
	private ShippingInfo shippingInifo;
    ...
    
    // 도메인 모델 엔티티는 도메인 기능도 함께 제공
    public void changeShippingInfo(ShippingInfo newShippinginInfo) {
    	checkShippingInfoChangeable();
        setShippingInfo(newShippingInfo);
    }
    
    private void setShippingInfo(ShippingInfo newShippingInfo) {
    	if (newShippingInfo == null) {
        	throw new IllegalArgumentException();
        }
        
        // 밸류 타입의 데이터를 변경할 때는 새로운 객체로 교체한다.
        this.shippingIinfo = newShippingInfo;
    }

애그리거트

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

지도를 볼 때, 상세히 세부를 구체화한 대축척 지도만으로는 어디에 있는지 이해하기 어렵다.
- 이러한 경우, 큰 수준에서 보여주는 소축척 지도를 함께 봐야 한다.
- 이와 비슷하게 도메인 모델도, 세부 정보가 아니라 상위 수준에서 모델을 볼 수 있어야 전체 모델의 관계와 개별 모델을 이해하는 데 도움이 된다.
  - 도메인 모델에서 전체 구조를 이해하는데 도움이 되는 것이 바로 애그리게이트(Aggregate)이다.

애그리게이트(Aggregate)
- (개별 객체가 아닌) 관련 객체를 묶어서 객체 군집 단위로 모델을 바라볼 수 있게 된다.
  - 개별 객체간의 관계가 아닌 애그리거트 간의 관계로 도메인 모델을 이해하고 구현할 수 있게 되며, 이를 통해 큰 틀에서 도메인 모델을 관리할 수 있게 된다.
- 루트 엔티티를 갖는다.
  - 루트 엔티티는 군집에 속한 객체들을 관리한다.
  - 루트 엔티티는 애그리거트에 속해 있는 엔티티와 밸류 객체를 이용해서 애그리거트가 구현해야 할 기능을 제공한다.
  - 애그리거트를 사용하는 코드는 애그리거트 루트가 제공하는 기능을 실행하고 애그리거트 루트를 통해서 간접적으로 애그리거트 내의 다른 엔티티나 밸류 객체에 접근하게 된다.

public class Order {

	...
    public void changeShippingInfo(ShippingInfo newInfo) {
    	checkShippingInfoChangeable(); // 배송지 변경 가능 여부 확인
        this.shippingInfo = newInfo;
    }
    
    private void checkShippingInfoChangeable() {
    	... 배송지 정보를 변경할 수 있는지 여부를 확인하는 도메인 규칙 구현
    }
    
}

애그리거트 루트(Order)가 애그리거트에 속한 객체를 관리한다.
- checkShippingInfoChangeable()는 배송지를 변경할 수 있는지 확인한다.
- 주문 애그리거트는 Order를 통하지 않고 100000ShippingInfo를 변경할 수 있는 방법을 제공하지 않는다.
  - 배송지를 변경하려면, 반드시 루트 엔티티인 Order를 사용해야 하므로, 반드시 Order가 구현한 도메인 로직을 항상 따라야 한다.

애그리거트를 구현할 때는 고려할 것이 많다. 애그리거트를 어떻게 구성했느냐에 따라 구현이 복잡해지기도 하고 트랜잭션 범위가 달라지기도 한다. 또한 선택한 구현 기술에 따라 애그리거트 구현이 제약이 생기기도 한다.

리포지터리

리포지터리(Repository)
- 도메인 객체를 지속적으로 사용하기 위해 물리적인 저장소(RDBMS, NoSQL, 로컬 파일 등)에 도메인 객체를 보관하기 위한 도메인 모델
- 엔티티나 벨류가 요구사항에서 도출되는 도메인 모델이라면, 리포지터리는 구현을 위한 도메인 모델이다.
- 애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의한다.

public interface OrderRepsitory {
	public Order findByNumbre(OrderNumber number);
    public void save(Order order);
    public void delete(Order order);
    ...
}

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

public class CancelOrderService {
	prviate OrderRepository orderRepository;
    
    public void cancel(OrderNumber number) {
    	Order order = orderRepository.findByNumber(number);
        if (order == null) throw new NoOrderException(number);
        order.cancel();
    }
    
    ... DI 등의 방식으로 OrderRepository 객체 전달
}

도메인 모델을 사용해야 하는 코드는 리포지터리를 통해서 도메인 객체를 구한 뒤에 도메인 객체의 기능을 실행하게 된다.
- OrderRepsitory
  - 도메인 객체를 영속화하는 데 필요한 기능을 추상화한 것.
  - 고수준 모듈
- OrderRepository 구현 클래스
  - 저수준 모듈, 인프라 스트럭쳐

@Configuration
public class OrderServiceConfig { // 응용 서비스 영역 설정
	@Autowired
    private OrderRepository orderRepository;
    
    @Bean
    public CancelOrderService cancelOrderService() {
    	return new CancelOrderService(orderRepsitory);
    }
}

@Configuration
public class RepositoryConfig { // 인프라스트럭처 영역 설정
	@Bean
    public JpaOrderRepository orderRepository() {
    	return new JpaOrderRepository();
    }
    
    @Bean
    public LocalContainerEntityManagerFactoryBean emf() {
    	...
    }
    
}

응용 서비스와 리포지터리는 밀접한 연관이 있다.
- 이유1. 응용 서비스는 필요한 도메인 객체를 구한거나 저장할 때 리포지터리를 사용한다.
- 이유2. 응용 서비스는 트랜잭션을 관리하는데, 트랜잭션 처리는 리포지터리 구현 기술에 영향을 받는다.
리포지터리의 사용 주체가 응용 서비스이기 때문에 리포지터리는 응용 서비스가 필요로 하는 메서드를 제공한다.

5. 요청 처리 흐름

표현 영역
- 사용자가 전송한 데이터 형식이 올바른지 검사
- 문제가 없다면 데이터를 이용해 응용 서비스에 기능 실행을 위임한다.
응용 서비스
- 도메인 모델을 이용해 기능을 구현한다.
- 기능 구현에 필요한 객체를 리포지터리에서 가져와 실행하거나, 신규 도메인 객체를 생성해 리포지터리에 저장한다.
- 두 개 이상의 도메인 객체를 사용해서 구현한다.
예매하기, 예매 취소와 같은 기능을 제공하는 응용 서비스는 도메인 상태를 변경하므로, 변경 상태가 물리 저장소에 올바르게 반영되도록 트랜잭션을 관리해야 한다.

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

6. 인프라스트럭처 개요

인프라스트럭처(infrastructure)
- 표현, 응용, 도메인 영역을 지원한다.
- 도메인 객체의 영속성 처리, 트랜잭션, SMTP 클라이언트, REST 클라이언트 등 다른 영역에서 필요로하는 프레임워크, 구현 기술, 보조 기능을 지원한다.
도메인 영역과 응용 영역에서 인프라스트럭처의 기능을 직접 사용하는 것 보다, 이 두 영역에 정의한 인터페이스를 인프라스트럭처 영역에서 구현하는 것이 시스템을 더 유연하고 테스트하기 쉽게 만들어준다.

7. 모듈 구성

아키텍처의 각 영역은 별도 패키지에 위치한다.
- 도메인이 크면 하위 도메인으로 나누고 각 하위 도메인마다 별도 패키지를 구성한다.
- domain 모듈은 도메인에 속한 애그리거트를 기준으로 다시 패키지를 구성한다.
모듈 구조를 얼마나 세분화해야 하는지에 대해 정해진 규칙은 없다.
- 한 패키지에 너무 많은 타입이 몰려서 코드를 찾을 때 불편한 정도만 아니면 된다.
- 저자는 한 패키지에 가능하면 10개 미만으로 타입 개수를 유지하려고 노력한다고 한다.
  - 이 개수가 넘어가면 모듈을 분리하는 시도를 해본다.

Reference

[책] DDD START!: 도메인 주도 설계 구현과 핵심 개념 익히기 - 최범균

bien

Good Luck!

이전 포스트

[책]DDD START! #1. 도메인 모델 시작

다음 포스트

[책]DDD START! #2. 아키텍처 개요

DDD_START!

1. 네 개의 영역

표현영역

응용영역

도메인 영역

인프라 스트럭처

2. 계층 구조 아키텍처

계층 구조의 아키텍처 구성

구현의 편리함을 위해 유연한 계층구조 적용

의존성 문제 예시

인프라스트럭처 코드

응용영역 코드

3. DIP

고수준 모듈과 저수준 모듈

응용계층 코드: 추상화 적용

인트라스트럭쳐 코드: 추상화 이용

DIP 주의사항

DIP와 아키텍처

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

엔티티와 밸류

차이점1. 데이터와 함께 기능을 제공

차이점2. 벨류 타입을 이용해 표현

밸류; 불변 구현

애그리거트

리포지터리

5. 요청 처리 흐름

6. 인프라스트럭처 개요

7. 모듈 구성

Reference

[책]DDD START! #1. 도메인 모델 시작

[책]DDD START! #3. 애그리거트

0개의 댓글