1일 1커밋 !

본 게시물은 [도메인 주도 개발 시작하기] 를 읽고 정리 한 글입니다.

1. 아키텍처

전형적으로 아키텍처를 설계할 때는 4가지 영역으로 나눈다.

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

네 영역 중 표현 영역은 사용자의 요청을 받아 응용 영역에 전달하고 응용 영역의 처리 결과를 다시 사용자에게 보여주는 역할을 한다. 이때 사용자가 웹 브라우저를 사용하는 사람일 수도 있고 API 를 호출하는 외부 시스템일 수도 있다.

image

가장 흔한 방식으로 표현 영역에 HTTP 요청이 들어오고 이를 처리한 후에 JSON 형식 등으로 HTTP 응답을 전달한다. 처리에 대한 부분은 응용 영역에서 이루어지는데, 이 로직을 구현하기 위해서 도메인 영역의 도메인 모델이 사용된다. 사실상 응용 영역에서 직접 로직이 수행된다기보다는 도메인 모델에 로직 수행을 위임하는 것이다.

인프라스트럭처 영역은 구현 기술에 대한 것을 다룬다. 이 영역은 DB를 연동하고 SMTP 를 이용한 메일 발송 등의 실제 구현을 다룬다. 해당 영역에서 구현 기술에 대한 코드를 직접 만들고 다른 영역은 필요할 때 참조해 사용하는 방식이다.

1) 계층 아키텍처

image

네 영역을 구성할 때는 위와 같은 계층 구조를 가장 흔하게 사용한다. 계층 구조는 상위 계층에서 하위 계층으로의 의존만 존재한다. 하지만 대게 코드는 상세한 구현 기술을 다루는 인프라스트척처 계층에 종속된다.

다음은 Drools 라는 룰 엔진을 사용해 할인 금액을 계산한다고 하자.

public class DroolsRuleEngine{
	...
	public void evalute(...){...}
}

위와 같이 인프라스트럭처 계층의 코드가 존재한다.

public class CalculateDiscountService{
	private DroolsRuleEngine ruleEngine;

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

	public Money calculateDiscount(...){
		...

		MutableMoney money = new MutableMoney(0);
		List<?> facts = Arrays.asList(customer, money);
		facts.addAll(orderLines);
		ruleEngine.evalute(“discountCalculation”, facts);
		return money.toImmutableMoney();
	}
}

도메인 영역에서 할인된 금액을 계산하는 코드이다.

여기에는 크게 두 가지 문제가 있다.

(1) 테스트 어려움

CalculateDiscountService 를 테스트 하기 어렵다. 이를 테스트하기 위해서는 DroolsRuleEngine 에 의존적일 수 밖에 없다.

(2) 기능 확장의 어려움

현재 할인 계산을 위해 Drools 라는 룰 엔진을 사용하기 때문에 불필요한 코드들이 발생했다. MutableMoney 는 연산결과를 받기 위해 추가한 타입이며, facts 를 다루는 코드는 Drools 의 룰을 위해 필요한 데이터이다. 또한 evalute 의 “discountCalculation” 또한 Drools 의 세션 이름으로 상당히 많은 부분이 인프라스트럭처의 기술에 의존적인 코드이다. 즉, 다른 기술을 사용하기 위해서는 많은 부분에서 수정이 필요하다는 뜻이다.

2. DIP

가격계산에 대한 이야기를 계속 해보자. 가격 계산을 위해서 필요한 과정을 파악할 수 있다.

image

고수준 모듈은 의미 있는 단일 기능을 제공하는 모듈로 여기서는 할인 가격을 계산하는 기능을 수행한다. 고수준 모듈의 기능을 위해서는 여러 하위 기능이 필요한데, 구체적으로 고객 정보를 구하는 것과 룰을 사용한 계산이 이에 해당한다. 이 하위 기능을 실제 구현하는 것들이 저수준 모듈이다. JPA 를 이용해 고객 정보를 읽고, Drools 를 이용해 룰을 적용하는 것이 이에 해당한다.

하지만 일반적으로 고수준 모듈이 저수준 모듈을 사용하면 앞서 말한 테스트 어려움과 기능 확장의 어려움이라는 문제가 발생한다.

DIP 는 인터페이스 추상화를 통해 저수준 모듈이 고수준 모듈에 의존하도록 바꿔 문제를 해결한다.

public interface RuleDiscounter {
	Money discount(...);
}

public class CalculateDiscountService{
	private RuleDiscounter ruleDiscounter;

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

	public Money calculateDiscount(...){
		...

		return ruleDiscounter.discount(...);
	}
}

CalculateDiscountService 입장에서는 계산을 어떻게 구현했는 지는 중요하지 않다. 결국 룰 적용을 구현한 클래스는 RuleDiscounter 를 상속 받아 구현하기 때문에 일정한 틀을 갖출 수 있다. 실제 구현 클래스는 Drools 를 사용해 구현하든 아무 상관이 없다.

image

위는 Drools 를 사용해 구현 클래스를 작성했을 때의 구조이다. 구조에서도 CalculateDiscountService 는 더 이상 구현 기술인 Drools 에 의존하지 않는다.

image

이것이 앞서 말한 저수준 모듈이 고수준 모듈에 의존하는 것이다. RuleDiscounter 는 “룰을 이용한 할인 금액 계산” 이라는 고수준 모듈이며 이를 구현하는 구현 클래스는 저수준 모듈이다. 이처럼 고수준 모듈이 저수준 모듈을 사용하기 위해서는 고수준 모듈이 저수준 모듈에 의존해야하는데, 의존 관계를 역전 시켰기 때문에 DIP, Dependency Inversion Principle 이라 부른다.

당연하게도 구현하는 방식을 바꿔 구현 클래스가 교체되더라도 CalculateDiscountService 에서는 객체만 변경하면 된다. 또한 테스트 시 대역 객체를 사용해서 테스트를 진행할 수 있기 때문에 앞선 두 가지 문제점이 바로 해결되는 것을 확인할 수 있다.

1) 인터페이스와 구현 클래스의 분리?

DIP 에 있어서 가장 큰 오해이다. 위의 내용을 보고 단순히 인터페이스와 구현 클래스의 분리라고 생각할 수 있지만 DIP 의 핵심은 고수준 모듈이 저수준 모듈에 의존하지 않는 것이다.

image

위 같은 구조를 보면 인터페이스와 구현 클래스를 분리하였지만 여전히 도메인 영역이 인프라스트척처 영역에 의존하는 형태이다. 이는 “할인 금액 계산” 이라는 도메인, 고수준 모듈 관점에서 인터페이스를 도출한 것이 아니라 “룰 엔진” 이라는 인프라스트럭처, 저수준 모듈 관점에서 도출되었기 때문이다.

2) DIP 아키텍처

기존 아키텍처는 응용, 도메인 영역이 인프라스트럭처 영역을 의존했었다. 아키텍처에도 DIP 를 적용시키면 인프라스트럭처 영역이 응용, 도메인 영역에 의존하는 구조를 만들 수 있다.

image

위 구조를 자세히 나타내면 아래와 같다.

image

응용, 도메인 영역에서 의존하는 것들은 고수준의 인터페이스이다. 인프라스트럭처는 구현 클래스를 통해 해당 인터페이스에 의존하게 된다. 따라서 다른 영역에 영향을 최소화하면서 구현체를 변경시키거나 추가하는 일이 가능하게 된다!

3) 구현??

스프링을 사용할 경우 트랜잭션 처리에서는 @Transactional 을 사용할 수 있다. 또한 JPA 전용 어노테이션인 @Entity 나 @Table 등을 사용할 수 있다. 따라서 무조건 인프라스트럭처에 대한 의존을 없애라는 것이 아니라 구현의 편리함과 DIP 의 장점들을 잘 조합하고 다룰 필요가 있다.

3. 도메인 영역

image

1) 엔티티

(1) DB 테이블의 엔티티와 도메인 모델의 엔티티

두 모델의 가장 큰 차이점은 도메인 모델의 엔티티는 데이터와 도메인 기능도 함께 제공한다는 점이다. 이는 단순히 데이터를 담고 있는 구조가 아닌 기능도 함께 제공하는 객체이다. 또 도메인 모델의 엔티티는 밸류 타입을 사용할 수 있다는 것이다. DB 테이블에서는 밸류 객체가 별도의 테이블로 저장되기에 또 다른 엔티티로 보이기에 밸류 타입을 제대로 사용하기에는 어려움이 있다.

## 2) 애그리거트

애그리거트는 관련 객체 (엔티티와 밸류)를 하나로 묶은 군집이다. 도메인 모델이 복잡해지면 엔티티와 밸류 등 개별 요소에 빠질 수 있기에 상위 수준에서 모델을 바라보는데 도움을 준다.

image

객체들과의 관계에서 벗어나 객체 군집 단위인 애그리거트의 관계로 도메인 모델을 관리할 수 있다.

애그리거트에서 가장 핵심적이고 관리하는 역할의 엔티티를 루트 엔티티라 한다. Order, ShippingInfo, OrderLine, Orderer .. 등의 엔티티와 밸류 타입이 존재할 때, 모든 객체들은 Order 를 통해 기능하고 묶인다. 해당 묶음을 주문 애그리거트라 할 수 있으며 Order 엔티티가 해당 애그리거트의 루트 엔티티이다.

image

## 3) 리포지터리

리포지터리는 애그리거트 단위로 도메인 객체를 저장하고 조회하는 기능을 정의한다. 도메인 객체를 RDBMS, NoSQL 같은 물리적 저장소에 객체를 보관하기 위한 도메인 모델이다.

도메인 모델을 사용하는 코드는 리포지터리를 통해 도메인 객체를 구하고 기능을 수행한다. 이때 루트 엔티티를 찾고 저장하는데, 루트 엔티티로 애그리거트 단위의 일을 수행할 수 있기 때문이다.

리포지터리는 결국 도메인 객체를 영속화하는 데 필요한 기능을 추상화한 고수준 모듈에 속한다. JPA 를 사용한다면 편하게 JpaRepository 를 상속받아 사용할텐데 자세한 구조를 보자면 아래와 같은 것이다.

image

응용 서비스는 필요한 도메인 객체를 구하거나 저장해야하며 트랜잭션을 관리한다. 이때 응용 서비스는 리포지터리를 사용하거나 영향을 받을 수 밖에 없기에 둘은 긴밀한 연관이 있다. 다르게 말하자면 리포지터리를 사용하는 주체는 응용 서비스이기에 애거리거트를 저장하고 조회하는 기능이 필수적이다.

업데이트:

댓글남기기

참고