[도메인 주도 개발 시작하기] 인프라스트럭쳐 개요

1) 인프라스트럭쳐란?

- 인프라스트럭쳐(Infrastructure)는 표현 영역, 응용 영역, 도메인 영역을 지원한다.

  도메인 객체의 영속성 처리, 트랜잭션, SMTP 클라이언트, REST 클라이언트 등 다른 영역에서 필요로 하는

  프레임워크, 구현 기술, 보조 기능을 지원한다.

 

- DIP에서 언급한 것처럼 도메인 영역과 응용 영역에서 인프라스트럭처의 기능을 직접 사용하는 것보다

  이 두 영역에 정의한 인터페이스를 인프라스트럭처 영역에서 구현하는 것이

  시스템을 더 유연하고 테스트하기 쉽게 만들어준다.

 

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

  예를 들어, 스프링을 사용할 경우 응용 서비스는 트랜잭션 처리를 위해 

  스프링이 제공하는 @Transactional을 사용하는 것이 편리하다.

 

- 영속성 처리를 위해 JPA를 사용할 경우 @Entity나 @Table과 같은 JPA 전용 애너테이션을

  도메인 모델 클래스에 사용하는 것이 XML 매핑 설정을 이용하는 것보다 편리하다. 

// 구현의 편리함을 위해 인프라스트럭처에 대한 의존을 일부 도메인에 넣은 코드
// JPA의 @Table 애너테이션을 이용해서 엔티티를 저장할 테이블 이름을 지정했다
// XML 설정을 사용하는 것보다 편리하게 테이블 이름을 지정할 수 있다.

@Entity
@Table(name = "TBL_ORDER")
public class Order {
 ...
}

 

- 구현의 편리함은 DIP가 주는 장점(변경의 유연함, 테스트가 쉬움)만큼 중요하기 때문에  

  DIP의 장점을 해치지 않는 범위에서 응용 영역과 도메인 영역에서 구현 기술에 대한 의존을

  가져가는 것이 나쁘지 않다고 생각한다.

 

- 응용 영역과 도메인 영역이 인프라스트럭처에 대한 의존을 완전히 갖지 않도록 시도하는 것은

  자칫 구현을 더 복잡하고 어렵게 만들 수 있다.

 

- 좋은 예가 스프링의 @Transactional 어노테이션이다.

  @Transactional을 사용하면 한 줄로 트랜잭션을 처리할 수 있는데

  코드에서 스프링에 대한 의존을 없애려면 복잡한 스프링 설정을 사용해야 한다

  의존은 없앴지만 특별히 테스트를 더 쉽게 할 수 있다거나 유연함을 증가시켜주지 못한다. 

  단지, 설정만 복잡해지고 개발 시간만 늘어날뿐이다.

 

- 표현 영역은 항상 인프라스트럭처 영역과 쌍을 이룬다.

  스프링 MVC를 사용해서 웹 요청을 처리하면

  스프링이 제공하는 MVC 프레임워크에 맞게 표현 영역을 구현해야 하고,

  Vert.x를 사용해서 REST API 서버를 구축하려면 Vert.x에 맞게 웹 요청 처리 부분을 구현해야 한다.