[DDD] 아키텍처 개요 -4

해당 포스팅은 최범균 작가님의  도메인 주도 개발 시작하기 (P.88~93)를 읽고 정리한 글입니다.

 

요청 처리 흐름

사용자 입장에서 봤을 때 소프트웨어는 기능을 제공한다.

 

사용자가 애플리케이션에 기능 실행을 요청하면 그 요청을 처음 받는 영역은 표현 영역이다. 표형 영역은 사용자가 전송한 데이터 형식이 올바른지 검사하고 문제가 없다면 데이터를 이용해서 응용 서비스에 기능 실행을 위임한다. 이때 표현 영역은 사용자가 전송한 데이터를 응용 서비스가 요구하는 형식으로 변환해서 전달한다.

 

응용 서비스는 도메인 모델을 이용해서 기능을 구현한다. 기능 구현에 필요한 도메인 객체를 리포지터리에서 가져와 실행하거나 신규 도메인 객체를 생성해서 리포지터리에 저장한다.

---

인프라스트럭처 개요

인프라스트럭처는 표현 영역, 응용 영역, 도메인 영역을 지원한다. DIP에서 언급한 것처럼 도메인 영역과 응용 영역에서 인프라스트럭처의 기능을 직접 사용하는 것 보다 이 두 영역에 정의한 인터페이스를 인프스트럭처 영역에서 구현하는 것이 시스템을 더 유연하고 테스트하기 쉽게 만들어준다.

 

하지만 무조건 인프라스트럭처에 대한 의존을 없앨 필요는 없다. 예를 들어 응용 서비스는 트랜잭션 처리를 위해 스프링이 제공하는 @Transactional을 사용하는 것이 편리하다. 또한 영속성 처리를 위해 JPA를 활용할 경우 @Entity나 @Table과 같은 JPA 전용 애너테이션을 도메인 모델 클래스에 사용하는 것이 XML 매핑 설정을 이용하는 것보다 편리하다. 

 

구현의 편리함은 DIP가 주는 다른 장점(변경의 유연함, 테스트가 쉬움)만큼 중요하기 때문에 DIP의 장점을 해치지 않는 범위에서 응용 영역과 도메인 영역에서 구현 기술에 대한 의존을 가져가는 것이 나쁘지 않다고 생각한다. 응용 영역과 도메인 영역이 인프라스트럭처에 대한 의존을 와전히 갖지 않도록 시도하는 것은 자칫 구현을 더 복잡하고 어렵게 만들 수 있다.

---

DIP의 이점과 구현의 편리함에 관한 내용을 읽으며, 어떤 기술이나 원칙도 하나만 고수하는 것은 바람직하지 않다는 생각이 들었다. 상황에 따라 유연하게 판단하고, 다양한 고려사항 속에서 최적의 솔루션을 적용하는 것이 무엇보다 중요하다는 점을 다시금 깨달았다.