2장 아키텍처 개요

1. 계층 구조 아키텍처

네 영역을 구성할 때 많이 사용하는 아키텍처는 아래와 같다.

계층 구조를 엄격하게 적용한다면 상위 계층은 바로 아래의 계층에만 의존을 가져야 한다. 하지만 구현의 편리함을 위해 계층 구조를 유연하게 가져갈 수 있다.

 

구조가 엄격하든 유연하든 하위 계층은 상위 계층을 의존하지 않는다. 그 말은 표현, 응용, 도메인 계층이 상세한 구현 기술을 다루는 인프라 계층을 의존한다는 것이다. 그로 인해 테스트의 어려움과 기능 확장의 어려움을 야기한다. 아래에서 자세하게 알아보자.

 

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();
    }
  }
}

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(custome, money);
    facts.addAll(orderLines);
    ruleEngine.evalute("discountCalculation", facts);
    return money.toImmutableMoney();
  }
  ...
}

위의 코드를 보면 CalculateDiscountService가 DroolsRuleEngine을 의존하고 있다. Service 클래스를 테스트하려면 RulesEngine이 완벽하게 동작해야만 테스트가 가능하다. 또한, Drools에 특화된 코드가 Service 내부에 존재하기 때문에 변경에 유연하지 못하다는 문제를 인지할 수 있다. 이러한 문제를 어떻게 해결할 수 있을까?

 

2. DIP

위의 계층 구조는 테스트의 어려움과 변경에 유연하지 못하다는 단점이 존재한다. 이를 DIP로 해결할 수 있다.

저수준 모듈이 고수준 모듈을 의존하도록 DIP를 적용한 코드는 다음과 같다.

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

public class DroolsRuleDiscounter implements RuleDiscounter {
  private KieContainer kContainer;
    
  public DroolsRuleEngine() {
    KieServices ks = KieServices.Factory.get();
    kContainer = ks.getKieClasspathContainer();
  }

  @Override
  public void applyRules(String sessionName, List<?> facts) {
    KieSession ksession = kContainer.newKieSession(sessionName);
        
    try {
        facts.forEach(x -> ksession.insert(x));
        ksession.fireAllRules();
    } finally {
        kSession.dispose();
    }
  }
}

public class CalculateDiscountService {
  private RuleDiscounter ruleDiscounter;

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

Service는 더 이상 Drools에 의존하지 않는다. 대신 RuleCounter를 통해 룰을 적용한다는 사실만 알 뿐이다. 이를 도식화하면 아래와 같다.

저수준 모듈이 고수준 모듈을 의존하도록 구조를 변경함으로써 단점을 극복하였다. 구현 객체의 변경이 필요하면 설정 파일에서 변경하기만 하면 된다. 테스트는 RuleDiscounter가 인터페이스이므로 대역 객체를 사용해서 진행하면 된다.

 

인터페이스 분리 시 주의사항

DIP는 단순히 인터페이스와 구현 클래스를 분리하는 것이 아니다. 고수준 모듈이 저수준 모듈에 의존하지 않도록 분리하는 것이 중요하다.

왼쪽이 잘못된 예이고, 오른쪽이 올바른 예이다.

DIP를 적용할 때 하위 기능을 추상화한 인터페이스는 고수준 모듈 관점에서 도출한다. CalculateDiscountService는 이름을 보면 알 수 있듯이 가격 할인 계산이라는 기능을 구현한다. 그에 따라 RuleDiscount 인터페이스는 가격 할인을 위한 룰을 적용한다라는 하위 기능을 메서드로 가지고 있다. 별 의도 없이 DroolsRuleEngine가 그저 인터페이스를 구현하도록 한 것이 아니다.

 

이런 장점을 가지고 있는 DIP이지만, 모든 상황에서 인터페이스로 분리하는 것은 번거롭다. 이점이 있다고 판단되면 적용하자.

 

인프라스트럭처 주의사항

무조건 인프라스트럭처에 대한 의존을 없앨 필요는 없다.

 

@Entity, @Transactional과 같은 애노테이션은 인프라스트럭처에 해당된다. 이를 사용하면 의존성을 가지긴 하지만, 구현의 편리함이라는 장점이 훨씬 크기 때문이다.

 

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

요소	설명
애그리거트	애그리거트는 연관된 엔티티와 밸류를 개념적으로 하나로 묶은 것이다. 애그리거트는 구성 객체들을 관리하기 위해 루트 엔티티를 갖는다.
리포지터리	도메인 모델의 영속성을 처리한다. 애그리거트 단위로 저장하고 조회하는 기능을 정의한다.
도메인 서비스	특정 엔티티에 속하지 않은 도메인 로직을 제공한다. 가령 할인 금액 계산을 구현하기 위해서는 상품, 쿠폰, 회원 등급, 구매 금액 등 다양한 조건을 이용해서 구현해야 한다. 이렇게 도메인 로직이 여러 엔티티와 밸류를 필요로 하면 도메인 서비스에서 로직을 구현한다.

 

4. 모듈 구성

패키지를 어떻게 세분화해야 하는지 정해진 규칙은 없다. 단순히 4개의 영역으로 구분하거나 하위 도메인 별로 나누어도 된다. 도메인이 복잡하면 애그리거트(도메인 모델)와 도메인 서비스를 별도의 패키지에 위치시켜도 된다.

 

한 패키지에 너무 많은 타입이 몰려서 불편하지 않으면 된다. 필자는 가급적 한 패키지에 10 ~ 15개 미만으로 타입 개수를 유지하려 한다.