Chapter 2. 아키텍처 개요

아키텍처

👀  아키텍처의 전형전익 영역

- 표현, 응용, 도메인, 인프라스트럭처

표현 영역

• 사용자의 요청을 받아 응용 영역에 전달하고 응용 영역의 처리 결과를 다시 사용자에게 보여주는 역할
• 대표적인 표현 영역의 사용자는 웹 브라우저 이용자, REST API 를 호출하는 외부 시스템 등 

응용 영역

• 시스템이 사용자에게 제공해야 할 기능을 구현하고, 그러기 위해서 도메인 영역의 도메인 모델을 사용
• 로직을 직접 수행하기보다는 도메인 모델에 로직 수행을 위임

public class CancelOrderService {

   @Transactional
    public void cancelOrder(String orderId) {
    	Order order = findOrderById(orderId);
        if (order == null) throw new OrderNotFoundException(orderId);
        order.cancel(); // 도메인 모델 내부에 있는 주문 취소 로직에 해당하는 cancel() 사용
    }
    
}

 

도메인 영역

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

public class Order {
   private OrderStatus status;

   public void cancel() {
      this.status = OrderStatus.CANCELED;
   }
   
}

public enum OrderStatus {
   ...
   CANCELED,
   ...
}

 

인프라스트럭처 영역

• RDBMS, MongoDB, HBase 등 연동을 처리
• Message Queue에 message 를 전송 / 수신
• SMTP 메일 발송 

 

계층 구조 아키텍처

👀  네 영역을 구성할 때 많이 사용하는 아키텍처가 아래 그림과 같은 계층 구조

• 계층 구조는 상위 계층에서 하위 계층으로의 의존만 존재
  • ex) 응용 계층이 도메인 계층에는 의존하지만, 도메인 계층이 응용 계층에 의존하지는 않음
• 구현의 편리함을 위해 계층 구조를 유연하게도 적용 할 수 있음
  • ex) 응용 계층이 도메인 계층에도 의존하고, 외부 시스템과의 연동을 위해 인프라스트럭처 계층에도 의존하기도 함

📕 Rule Engine 이란 ?
- 룰 엔진을 롤(Rule; 규칙, 즉 로직)을 별도로 저장해두고 프로그램에서 룰을 가져다 쓸 수 있도록 해 주는 기능을 제공

Business Logic 이 매우 빈번하게 변경되는 경우, 어플리케이션의 수정이 매우 빈번하게 발생
따라서, 해당 로직을 룰 엔진으로 옮겨가고, 어플리케이션에서는 롤 엔진을 통해서 룰(로직)을 실행하도록 처리

ex) 매년 계속해서 변하는 세율에 따른 세금 계산 로직

 

DIP

👀  DIP 란?

- 의존 역전 원칙(Dependency Inversion Principle) : 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 되며, 저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 함 (자신보다 변하기 쉬운 것에 의존하지 마라)

 

• Ex) DIP 가 적용되지 않은 주문 시 할인율 적용 코드

class CalculateDiscountService { 
    private DroolsRuleEngine ruleEngine = new DroolsRuleEngine();

    public Money calculateDiscount(List<OrderLine> orderLines, String customerId) {
        Customer customer = findCustomer(customerId);

        // 초기 돈
        MutableMoney money = new MutableMoney(0);
        
        // DroolsRulsEngine 사용을 위한 조건 추가
        List<?> conditions = Arrays.asList(customer, money);
        conditions.addAll(orderLines);

        // DroolsRulsEngine을 이용해 할인율 적용
        ruleEngine.evaluate("discountCalculation", conditions);
        
        // 할인율 적용 된 돈을 불변으로 변경
        return money.toImmutableMoney();
    }
    
}

 

위 코드는 2가지 문제점을 가지고 있음

• 테스트하기 어려움
  • DroolsRuleEngine이 완벽하게 동작해야만 CalculateDiscountService를 테스트 가능
• 구현 방식을 변경하기 어려움
  • DroolsRuleEngine이 아니라 다른 엔진을 사용하도록 변경하고자 한다면 많은 부분이 변경되어야함

 

• Ex) DIP 가 적용된 주문 시 할인율 적용 코드

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

class CalculateDiscountService { 
    private RuleDiscounter ruleDiscounter;

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

    public Money calculateDiscount(List<OrderLine> orderLines, String customerId) {
        Customer customer = findCustomer(customerId);
        return ruleDiscounter.applyRules(customer, orderLines);
    }
}

class DroolsRuleDiscounter implements RuleDiscounter {

    @Override
    public Money calculateDiscount(List<OrderLine> orderLines, String customerId) {
       ...
    }
    
}

저수준 모듈이 고수준 모듈에 의존하도록 변경

• CalculateDiscountService 입장에서는 할인율 룰 적용을 어떤 엔진을 통해 구현했는지 중요하지 않음
  • 고객 정보와 구매 정보에 할인율 룰을 적용해서 할인 금액을 구한다는 사실만 중요
• CalculateDiscountService 는 더 이상 구현 기술인 DroolsRuleDiscounter 에 의존하지 않고 추상화한 고수준 모듈인 RuleDiscounter 에 의존

 

위 2가지 문제도 해결 할 수 있음

• 테스트하기 쉬움
  • 특정 클래스가 아니라 인터페이스에 의존하므로 mockito를 사용한 stub 등을 사용한다면 직접 구현체를 구현하지 않고도 테스트를 진행할 수 있게 된다

public class CalculateDiscountServiceTest {

   @Test(expected = NoCustomerException.class);
   public void noCustomer_thenExceptionShouldBeThorwn() {
      // 테스트 목적의 대용 객체를 생성
      CustomerRepository stubRepo = mock(CustomerRepository.class);
      when(stubRepo.findById("noCustomerId")).thenReturn(null);
      
      RuleDiscounter stubRule = (customer, lines) -> null;
      
      // 테스트 목적의 대용 객체를 주입받아 테스트 진행
      CalculateDiscountService calcDiscountService = new CalculateDiscountService(stubRepo, stubRule);
      calcDiscountService.calculateDiscount(someLines, "noCustomerId");
   }

}

 

• 구현 방식을 변경하기 쉬움
  • 저수준 모듈에 강하게 결합되어 있는 구조가 아니기 때문에, 구현 기술을 변경하더라도 CalculateDiscountService를 수정할 필요가 없음

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

// 사용할 저수준 객체 변경 (또다른 저수준 모듈 사용)
RuleDiscounter ruleDiscounter = new SimpleRuleDiscounter();

// 생성자 방식으로 주입하고, 저수준 모듈을 위 같이 변경하더라도 고수준 모듈은 수정할 필요 없음
CalculateDiscountService discountService = new CalculateDiscountService(ruleDiscounter);

 

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

• 엔티티
  • 고유의 식별자를 가지고 자신의 라이프 사이클을 갖는 객체
  • 데이터와 데이터와 관련된 기능을 함께 제공
  • ex) 주문(Order), 회원(Member), 상품(Product)
  • 도메인 모델의 엔티티와 DB 모델의 엔티티는 다름
    • RDBMS는 밸류를 제대로 표현하기 힘듬
    • ORDER_NAME, ORDER_EMAIL 필드로 표시하거나 또는 ORDER_ORDERER 테이블로 표시하더라도 딱히 밸류 타입의 의미가 드러나지 않음
• 밸류
  • 고유의 식별자를 갖지 않고 주로 도메인 객체의 속성을 표현할 떄 사용되는 객체
  • 엔티티의 속성으로 뿐만 아니라, 다른 밸류 타입의 속성으로도 사용될 수 있음
• 애그리거트
  • 관련된 엔티티와 밸류 객체를 개념적으로 하나로 묶은 것
  • 도메인이 커질수록 개발할 도메인 모델도 커지게 되고, 많은 엔티티와 벨류가 생기면서 모델이 점점 더 복잡해짐
    -> 개발자가 전체 구조가 아닌 한개 엔티티와 벨류에 집중하게 되는 경우가 발생
  • 애그리거트를 통해 도메인 모델을 개별 객체가 아니라 상위 수준에서 모델을 볼 수 있어야 전체 모델과 개별 모델을 이해하는데 도움이 됨
  • 애그리거트는 군집에 속한 객체들을 관리하는 루트 엔티티를 가짐
  • 루트 엔티티는 애그리거트에 속해 있는 엔티티와 밸류 객체를 이용해서 애그리거트가 구현해야 할 기능을 제공
  • ex) Order 루트 엔티티, OrderLine 밸류, Orderer 밸류 -> 주문 애그리거트
• 리포지터리
  • 도메인 객체를 지속적으로 사용하려면 RDBMS 같은 물리적 저장소에 도메인 객체를 보관해야 하고, 이를 위한 도메인 모델
  • 도메인 모델의 영속성을 처리함
  • 리포지터리는 도메인 객체를 영속화하는데 필요한 기능을 추상화 한 것이기 때문에 고수준 모듈에 속하고, 실제 구현 클래스는 인프라스트럭쳐 영역에 속함
  • 응용 서비스는 필요한 도메인 객체를 구하거나 저장할 때 리포지터리를 이용
• 도메인 서비스
  • 특정 엔티티에 속하지 않은 도메인 로직을 제공함
  • 도메인 로직이 여러 엔티티와 벨류를 필요로 할 경우 여기에서 로직을 구현한다
  • ex) "할인 금액 계산" 을 구현하기 위해서는 상품, 쿠폰, 회원 등급, 구매 금액 등 다양한 엔티티와 밸류가 필요

 

모듈 구성

• 기본적으로 우리는 항상 아키텍쳐가 각 영역이 별도 패키지에 위치하는 형태로 구성

com.myshop.interface
com.myshop.application
com.myshop.domain
com.myshop.infrastructure

 

• 도메인이 크면 하위 도메인마다 별도 패키지를 구성

// 회원 도메인
com.myshop.member.interface
com.myshop.member.application
com.myshop.member.domain
com.myshop.member.infrastructure

// 주문 도메인
com.myshop.order.interface
com.myshop.order.application
com.myshop.order.domain
com.myshop.order.infrastructure​

 

• 도메인 내부에서 서로다른 애그리거트로 나눠지는 경우 분리할 수 있음

com.myshop.order.interface
com.myshop.order.application
com.myshop.order.domain.product
com.myshop.order.domain.category
com.myshop.order.infrastructure

 

• 만약 도메인 서비스 계층이 따로 있으면 아래와 같이 나뉠 수 있음

com.myshop.order.domain.product
com.myshop.order.domain.category
com.myshop.order.domain.service

모듈 구성에 정답은 없지만 가능하면 한 패키지내에 10개 미만으로 도메인 타입 개수를 유지하는 것이 GOOD

 

 

---

최범균 작가님의 DDD START! 2장을 요약했습니다.