[DDD] 응용 서비스와 표현 영역 -3

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

 

응용 서비스의 구현

응용 서비스는 표현 영역과 도메인 영역을 연결하는 매개체 역할을 하는데 이는 디자인 패턴에서 파사드와 같은 역할을 한다.

NOTE. 파사드패턴
복잡한 내부 서브시스템들의 다양한 인터페이스를 감추고, 클라이언트가 더 단순한 방식으로 해당 기능들을 사용할 수 있도록 하나의 통합된 고수준 인터페이스를 제공하는 구조 패턴이다.

이 절에서는 응용 서비스를 구현할 때 몇 가지 고려할 사항과 트랜잭션과 같은 구현 기술의 연동에 대해 살펴본다.

응용 서비스의 크기

응용 서비스 구현은 어렵지 않지만 몇 가지 생각할 거리가 있다.  그중 하나가 응용 서비스의 크기다. 응용 서비스는 보통 다음의 두 가지 방법 중 한 가지 방식으로 구현한다.

• 한 응용 서비스 클래스에 회원 도메인의 모든 기능 구현하기
• 구분되는 기능별로 응용 서비스 클래스를 따로 구현하기

한 클래스에 모든 기능을 구현하면 중복 로직 제거는 가능하지만, 클래스가 비대해지고 연관성 낮은 코드가 뒤섞여 유지보수가 어려워지는 단점이 있다. 반면, 기능별로 응용 서비스 클래스를 분리하면 클래스 수는 증가하지만 각 클래스의 응집도가 높아지고, 필요한 의존성만 포함하여 코드 품질을 일정 수준으로 유지할 수 있다. 다만, 이 방식은 여러 클래스에 동일한 로직이 중복될 수 있는데, 이 경우 공통 로직을 별도의 클래스로 분리해 재사용함으로써 중복을 방지할 수 있다.

응용 서비스의 인터페이스와 클래스

응용 서비스를 구현할 때 논쟁이 될 만한 것이 인터페이스의 필요성이다.

 

인터페이스가 필요한 몇 가지 상황이 있는데 그중 하나는 구현 클래스가 여러 개인 경우이다. 하지만 구현 클래스가 한 개일 때 인터페이스와 클래스를 따로 구현하면 소스 파일만 많아지고 구현 클래스에 대한 간접 참조가 증가해서 전체 구조가 복잡해진다.

 

TDD를 할 때, 표현 영역부터 개발을 시작한다면, 미리 응용 서비스를 구현할 수 없으므로 응용 서비스의 인터페이스부터 작성하게 된다. 하지만 Mockito와 같은 테스트 도구는 클래스에 대해서 테스트용 대역 객체를 만들 수 있기 때문에 응용 서비스에 대한 인터페이스가 없어도 표현 영역을 테스트할 수 있다. 이는 결과적으로 응용 서비스에 대한 인터페이스 필요성을 약화시킨다.

메서드 파라미터와 값 리턴

응용 서비스가 제공하는 메서드는 도메인을 이용해서 사용자가 요구한 기능을 실행하는 데 필요한 값을 파라미터로 전달받아야 한다. 스프링 MVC와 같은 프레임워크는 웹 요청 파라미터를 자바 객체로 변환하는 기능을 제공하므로 응용 서비스에 데이터로 전달할 요청 파라미터가 두 개 이상 존재하면 데이터 전달을 위한 별도의 클래스를 사용하는 것이 편리하다.

 

응용 서비스의 결과를 표현 영역에서 사용해야 하면 응용 서비스 메서드의 결과로 필요한 데이터를 리턴한다. 결과 데이터가 필요한 대표적인 예가 식별자이다. 식별자를 리턴하게 되면 표현 영역 코드는 응용 서비스가 리턴한 값을 사용해서 사용자에게 알맞은 결과를 보여줄 수 있게 된다.

 

애그리거트 객체를 그대로 리턴할 수도 있다. 하지만 이렇게 된다면 도메인 로직 실행을 응용 서비스와 표현 영역 두 곳에서 할 수 있기 때문에 코드 응집도를 낮추는 원인이 된다. 응용 서비스는 표현 영역에서 필요한 데이터만 리턴하는 것이 기능 실행 로직의 응집도를 높이는 확실한 방법이다.

표현 영역에 의존하지 않기

응용 서비스의 파라미터 타입을 결정할 때 주의할 점은 표현 영역과 관련된 타입을 사용하면 안 된다는 점이다. 이렇게 되면 응용 서비스만 단독으로 테스트하기 어려워진다. 또한 응용 서비스가 표현 영역 역할까지 대신하는 상황이 벌어질 수 있다.

트랜잭션 처리

트랜잭션을 관리하는 것은 응용 서비스의 중요한 역할이다. 스프링과 같은 프레임워크가 제공하는 트랜잭션 관리 가능을 이용하면 쉽게 트랜잭션을 처리할 수 있다. 프레임워크가 제공하는 트랜잭션 기능을 적극 사용하는 것이 좋다. 프레임워크가 제공하는 규칙을 따르면 간단한 설정만으로 트랜잭션을 시작하여 커밋하고 익셉션이 발생하면 롤백할 수 있다.

---

표현 영역

표현 영역의 책임은 크게 다음과 같다.

1. 사용자가 시스템을 사용할 수 있는 흐름(화면)을 제공하고 제어한다.
2. 사용자의 요청을 알맞은 응용 서비스에 전달하고 결과를 사용자에게 제공한다.
3. 사용자의 세션을 관리한다.

표현 영역의 첫 번째 책임은 사용자가 시스템을 사용할 수 있도록 적절한 흐름을 제공하는 것이다. 웹 서비스의 표현 영역은 사용자가 요청한 내용을 응답으로 제공한다. 사용자는 표현 영역이 제공한 폼에 알맞은 값을 입력하고, 다시 폼을 표현 영역에 전송한다. 표현 영역은 응용 서비스를 이용해 요청을 처리하고 그 결과를 응답으로 전송한다.

 

표현 영역의 두 번째 책임은 사용자의 요청에 맞게 응용 서비스에 기능 실행을 요청하는 것이다. 표현 영역은 사용자의 요청 데이터를 응용 서비스가 요구하는 형식으로 변환하고, 응용 서비스의 결과를 사용자에게 응답할 수 있는 형식으로 변환한다. MVC 프레임워크는 HTTP 요청 파라미터로부터 자바 객체를 생성하는 기능을 지원하므로, 자바 객체를 손쉽게 생성할 수 있다. 응용 서비스의 실행 결과를 사용자에게 알맞은 형식으로 제공하는 것도 표현 영역의 몫이다.

 

표현 영역의 또 다른 주된 역할은 사용자의 연결 상태인 세션을 관리하는 것이다.

---

아키텍처 설계에서 각 레이어의 책임을 명확히 구분하고, 서로의 역할을 침범하지 않는 것이 중요하다는 점을 깨달았다. 이를 통해 각 구성 요소의 응집도를 높이고, 결과적으로 전체 코드의 품질을 향상할 수 있다는 점에서 의미 있는 인사이트를 얻었다.