6장 응용 서비스와 표현 영역

1. 표현 영역과 응용 영역

앞서 우리는 소프트웨어로 해결하고자 하는 영역이 도메인이라는 점을 학습하였다. 그러나 이것만으로 끝나는 것이 아니다. 사용자와 도메인 영역을 연결해 주는 매개체인 표현 영역과 응용 영역이 필요하다.

 

2. 응용 영역(응용 서비스)

1. 역할

응용 서비스의 역할은 다음과 같다.

1. 사용자(클라이언트)가 요청한 기능을 실행한다.

 코드의 응집성을 높이고 코드 중복을 제거하기 위해, 도메인 로직 없이 그저 도메인의 기능을 실행하는 역할만 한다.

2. 트랜잭션 처리를 담당한다.

 기능 실행 도중에 문제가 발생하면 초기 상태로 되돌아 갈 수 있어야 한다.

 

다만 조회 기능만 필요한 경우라면, 응용 서비스 없이 구현하는 것을 고려해도 좋다.

2. 크기

응용 서비스의 크기를 어떻게 하느냐에 따라 구현 방식이 1) `한 응용 서비스 클래스에 회원 도메인의 모든 기능 구현하기` 2) `구분되는 기능별로 응용 서비스 클래스를 따로 구현하기`로 나뉜다.

 

방식 1) 한 응용 서비스 클래스에 회원 도메인의 모든 기능 구현하기

장점 : 도메인에 관련된 기능을 구현한 코드가 한 클래스에 위치하므로, 각 기능에서 동일 로직에 대한 코드 중복을 쉽게 제거할 수 있다.

  ex) 여러 메서드에 있는 null값 검사 기능을 별도의 메서드로 추출

단점 : 한 서비스 클래스의 크기(코드 줄 수)가 커진다. 그로 인해 관련 없는 코드가 추가되면서 코드의 품질이 저하된다.

 

방식 2)  구분되는 기능별로 응용 서비스 클래스를 따로 구현하기 -> 글쓴이가 선호하는 방식

장점 : 코드의 품질을 유지할 수 있고, 클래스별로 필요한 의존 객체만 보유할 수 있다.

단점 : 클래스의 개수가 많아진다.

 

3. 인터페이스와 클래스

인터페이스와 클래스를 따로 구현하면 1) 소스 파일이 많아지고 2) 구현 클래스에 대한 간첩 참조가 증가해서 전체 구조가 복잡해진다. 따라

서 필요한 상황(ex. 구현 클래스가 여러 개인 경우)에만 만드는 것을 고려하자.

 

4. 메서드 파라미터

응용 서비스는 필요한 값을 개별 파라미터나 별도의 dto로 전달받을 수 있다. 보통 요청 파라미터가 두 개 이상이면 dto를 사용하는 것이 편리하다.

여기서 주의할 점은 HttpServleRequest와 같이 표현 영역과 관련된 타입을 사용하지 않는 것이다. 표현 영역에 의존이 발생하면 1) 응용 서비스만 단독으로 테스트하기 어렵고 2) 표현 영역이 변경되면 응용 서비스 구현이 변경될 수 있다. 3) 응용 서비스가 표현 영역의 역할까지 대신한다는 단점도 존재한다.

 

5. 값 리턴

응용 서비스에서 애그리거트 자체를 리턴하면 코딩은 편할 수 있다. 하지만 도메인 로직 실행을 응용 서비스와 표현 영역 두 곳에서 할 수 있게 된다. 이는 곧, 기능 실행 로직이 두 영역에 분산되기 때문에 코드의 응집도를 낮추는 원인이 된다. 추가로 JPA에서 OSIV 설정을 false로 하는 경우, 지연 로딩이 서비스 단까지만 가능하기 때문에 더더욱 애그리거트를 표현 영역에 리턴하지 말자.

 

4. 표현 영역

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

1) 사용자가 시스템을 사용할 수 있는 화면을 제공하고 제어한다.

2) 사용자의 요청을 응용 서비스에 전달하고, 그 결과를 사용자에게 제공한다.

3) 사용자의 세션을 관리한다.

 

5. 값 검증

원칙적으로는 모든 값에 대한 검증은 응용 서비스에서 처리한다. 다만 구현의 편리함을 위해 다음처럼 구현하는 것을 고려해도 좋다.

- 표현 영역 : 필수 값, 값의 형식, 범위 등을 검증한다. -> 필드 에러 검증

- 응용 서비스 : 데이터의 존재 유무와 같은 논리적 오류를 검증한다. -> 글로벌 에러 검증

 

글쓴이는 코드 작성의 불편함보다는 응용 서비스의 완성도가 높아지는 이점이 더 크다고 하였다. 하지만 그 이점이 무엇인지는 서술하지 않았기 때문에 이 부분은 찾아봐야겠다.