: 인프라스트럭처는 표현 영역, 응용 영역, 도메인 영역을 지원하는 계층, 도메인 객체의 영속성 처리, 트랜잭션, SMTP 클라이언트, REST 클라이언트 등 다른 영역에서 필요로 하는 프레임워크, 구현 기술, 보조기능을 지원, DIP에서 언급한 것처럼 도메인 영역과 응용 영역에서 인프라스트럭처의 기능을 직접 사용하는 것보다 이 두 영역에 정의한 인터페이스를 인프라스트럭처 영역에서 구현하는 것이 시스템을 더 유연하고 테스트하기 쉽게 만들어 준다.
: 그렇다고 무조건 인프라스트럭처에 대한 하위 의존성을 없앨 필요는 없다. 예를 들어 스프링을 사용할 경우 응용 서비스는 트랜잭션 처리를 위해 스프링이 제공하는 @Transcational을 사용하는 것이 편리하다. 영속성 처리를 위해 JPA를 사용할 경우, @Entity, @Table과 같은 JPA 전용 애너테이션을 도메인 모델 클래스에 사용하는 것이 XML 매핑 설정을 이용하는 것보다 편리하다.
: 구현의 편리함은 DIP가 주는 다른 장점만큼 중요하기 때문에 DIP의 장점을 해치지 않는 범위에서 응용 영역과 도메인 영역에서 구현 기술에 대한 의존성을 가져가는 것도 나쁘지는 않다고 본다. 필자는, 응용 영역과 도메인 영역이 인프라스트럭처에 대한 의존을 완전히 갖지 않도록 시도하는 것은 자칫 구현 과정에서 그 복잡성을 늘릴 위험성이 존재한다.
: 좋은 예가 @Transactional인데, 이를 사용하면 트랜잭션 처리를 한 줄로 해결할 수 있다. 하지만 코드에서 스프링에 대한 의존을 없애려면 복잡한 스프링 설정을 사용해야 한다. 그렇다고 해서 테스트를 더 쉽게할 수 있다거나 유연함을 증가시켜주진 못하며 단지 설정만 복잡해지고 개발 시간만 늘어날 뿐이다.
