도메인 주도 개발의 아키텍처

[juu-n-oo]

아키텍처 개요

아키텍처 설계에서 주요 4가지 영역은 표현, 응용, 도메인, 인프라로 나눌 수 있다.

• 표현

  요청을 응용 영역이 필요로 하는 형식으로 변환하고, 응용 영역의 응답을 적절히 변환하여 전송함

• 응용

  응용 영역은 도메인 모델을 이용해서 사용자에게 제공할 기능을 구현하고, 실제 도메인 로직 구현은 도메인 모델에 위임한다.

• 도메인

  도메인 모델은 도메인의 핵심 로직을 구현함

• 인프라

  DB연동을 처리하고, 메시징 큐에 메시지를 전송/수신함.
  또는, HTTP 클라이언트를 이용해 REST API 호출

특정 인프라 기술에 대한 하위 계층의 의존성 발생

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

하지만, 외부 시스템과의 연동을 위해서 응용 계층과 도메인 계층이 인프라 계층에 의존하게 될 수 있다.

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

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

응용 영역에 해당하는 CalculateDiscountService에서 인프라 영역의 RoolEngine을 사용한다.

해당 Service가 겉으로는 인프라에 의존하지 않는것으로 보이나, 실제로는 Drools라는 특정 기술에 완전 의존하고 있다. 만약 Drools가 아닌 다른 기술로 변경된다면 많은 코드를 변경해야한다.

DIP (dependency inversion principal)

가격 할인을 위해 필요한 것은 고객 정보와 주문 정보이며, 이 정보들에 룰을 실행해야 한다.

CalculateDiscountService는 고수준 모듈로, 의미 있는 단일 기능(가격 할인 계산)을 제공한다. 이러한 고수준 모듈의 기능을 구현하기 위해서는 하위 기능들이 필요하다. 하위 기능에 해당하는 것은 다음과 같다.

• 고객 정보 구하기
• 룰 실행

이런 하위기능들은 저수준 모듈에서 구현되는데, 고객 정보를 가져오기 위해 JP를 이용하거나, 룰 실행을 위해 Drools를 실행하는 것에 해당한다.

public class CalculateDiscountService {
	private DroolsRuleEngine ruleEngine;
	
	public CalculateDiscountService() {
		ruleEngine = new DroolsRuleEngine();
	}
	
	public Money claculateDiscount(List<OrderLine> orderLInes, String customerId) {
		Customer customer = findCustomer(customerId);
		//...
		
		ruleEngine.evaluate("discountCalculation", facts);
		return money.toImmutableMoney();
	}
}

그럼, 고수준 모듈이 제대로 동작하기 위해서는 저수준 모듈을 사용해야하는데, 여기서의 문제는 고수준 모듈이 저수준 모듈에 의존하게 되어 구현 변경이나 테스트가 어렵다는 문제가 발생한다.

SOLUTION!

DIP는 저수준 모듈이 고수준 모듈에 의존하도록 바꾼다. 고수준 모듈을 구현하려면 저수준 모듈을 사용해야 하는데, 반대로 저수준 모듈이 고수준 모듈에 의존하도록 하려면 어떻게 해야하나? 이는 추상화한 인터페이스를 통해 해결할 수 있다.

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

위의 추상화 인터페이스를 서비스단에서 사용하도록 만든다.

public class CalculateDiscountServer {
	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);
	}
}

이제 서비스는 Drools(저수준 모듈)에 의존하는 코드가 한개도 없어졌다. 단지 RuleDiscounter를 사용해서 룰을 적용한다는 것으로 변경되었다. 실제 RuleDiscounter 구현체는 생성자를 통해서 전달받는다.

그렇다면 실질적인 룰을 실행하는 RuleDiscounter 구현체는 추상화 인터페이스를 상속받아서 구현한다.

이제 서비스는 추상화한 RuleDiscounter에 의존하고 있을 뿐, 해당 인터페이스를 실제로 구현한 객체가 어떤 기술을 사용하고 있는지는 무관하다.

원래는 고수준 모듈(서비스)이 하위 기능을 위해 저수준 모듈(Discounter)을 사용하기때문에, 고수준 모듈이 저수준 모듈에 의존하게 되는데, 추상화 인터페이스를 사용함으로써 저수준 모듈(Discounter 구현체)가 고수준 모듈의 추상화 인터페이스(Discounter 인터페이스)를 의존하게 되면서 의존관계가 역전되게 되며, 이러한 것을 DIP라고 한다.