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

표현영역과 응용영역

 

표현영역과 응용영역은 사용자와 도메인을 연결시켜주는 매개체 역할을 한다.

 

 

표현영역(Controlelr)에서는 요청 파라미터, 쿠키, 헤더 등을 통해 사용자의 요청을 해석하며 실제 사용자가 원하는 기능을 실행하는것은 응용영역(Service)에서 처리된다.

 

Clean Architecture 에도 나왔던 내용으로 응용영역은 표현영역 보다 고수준 정책이므로 응용영역은 표현형역에 의존해서는 안된다. 즉, 응용영역에서는 응용영역에서 처리된 데이터의 결과를 표현영역에서 어떻게 처리, 표현 (json, html, 등) 되어 사용자에게 응답해줄지 신경쓰지 않아도 된다.

 

 

응용서비스의 역할

 

응용서비스는 주로 도메인 객체간 흐름을 제어한다.

앞선 장에서 나왔던 내용으로 도메인 영역 내에서 도메인서비스라는 요소도 존재한다.

 

도메인서비스와 응용서비스의 차이점은 도메인 서비스는 기능적으로 애그리거트의 상태를 변경하거나 상태 값을 계산하며 책임이 어느 애그리거트에 두어도 애매하다면 두는 서비스이며 응용서비스는 앞서 얘기한 도메인 보다 더 저수준 정책에 관한 비즈니스적인 도메인 객체간 소통이다. 예를들면 LoginService, JoinService와 같은 클래스를 응용서비스로 들 수 있을것같다.

 

 

도메인 로직 넣지않기

 

도메인에 대한 로직은 당연히 도메인 영역에 위치해야만 한다. 만약 도메인 로직이 응용영역에 위치한다면 다음과 같은 문제를 야기한다.

 

1. 코드 중복이 발생한다.

 

도메인관련 코드는 도메인이 책임을 가지고 구현하고, 퍼블릭인페이스로 외부에 제공되어야한다. 그리고 응용영역에서는 이 퍼블릭인터페이스를 사용하기위해 단순히 메시지만 전송하면 되지만 만일 도메인 로직이 응용영역에 위치해 응용영역에서 구현한다면 같은 여러 응용 영역 내 중복되는 도메인로직이 존재할 가능성이 높다.

 

2. 코드의 응집성이 떨어진다.

 

응용영역에 위치한 코드로 인해 해당 도메인 관련 코드를 분석할 때 도메인영역내의 로직뿐만이 아니라 여기저기 흩어져있는 응용영역도 탐사 해야한다.

 

 

응용서비스의 구현

 

응용서비스의 크기

 

응용서비스를 구현할 때 두가지의 경우를 생각해 볼 수 있다.

1. 한개의 서비스 클래스에 해당하는 모든 기능 구현하기 (ex. UserService)

2. 기능별로 서비스 클래스 구분해서 구현하기 (ex. UserJoinService, UserLoginService, UserWithdrawalService)

 

초반에 구현 할 기능이 많이 없을 때는 첫번째 방식이 코드 중복도 덜 발생하고 효율적일지도 모르지만 코드 내용이 점점 커지게되면 코드가 일관성이 적어지게된다. 기능을 추가할 수록 해당 클래스는 점점 무거워지고 의존성도 그 만큼 추가하게 될 것이다.

 

기능별로 서비스 클래스를 구현해서 코드 일관성을 유지시키고 공통적으로 사용되는 로직은 별도의 클래스 또는 추상클래스를 작성하여 해결하면 된다.

 

 

표현영역에 의존하지 않기

 

HttpServletRequest, HttpSession 등 표현영역에서 처리되는 객체는 응용영역에 파라미터로 전달하면 안된다.

전달하는 순간 부터 응용영역은 표현영역에 의존하게되며 파라미터로 전달 받은 해당 객체들을 통해 구현체를 구현 할 가능성이 높아진다,

또한 응용영역만 단독으로 테스트하기 어려워지고 표현영역이 변경되면 응용영역도 변경해야하는 이슈가 생긴다.

 

가장 좋은 예방법은 파라미터와 리턴타입으로 표현영역의 구현 기술을 사용하지 않는것이다.

 

 

값 검증

 

값에 대한 검증은 두 영역 모두에서 진행돼야 한다.

일반적인 방법으로 구분해보면 다음과 같다.

 

표현영역: 필수 값, 값의 형식, 범위 등을 검증

응용영역: 데이터의 존재 유무와 같은 논리적 오류를 검증

 

 

조회 전용 기능과 응용 서비스

 

일반적인 MVC 프레임워크에서는 표현영역(Controller)에서 인프라스트럭쳐(DAO or Repository) 사이에 응용영역(Service)이 퍼사드 역할을 하여 데이터를 조회 하는 구조는 작성되지만, 저자는 응용영역이

 

public class OrdersService {

    public List<OrderView> getOrders(String orderId) {
        return orderViewDao.selectByOrderer(orderId);
    }
    ...
}

 

위의 코드와 같이 별다른 기여가 없다면 굳이 응용영역을 거치지않고 표현영역에서 인프라스트럭처를 바로 사용하여 데이터를 조회해도 된다고 말한다.

 

하지만 추후에 정책의 내용이 추가되어 응용영역에 한줄이라도 로직이 추가되어야 하는 순간 구조를 재설계해야할 수도 있을것 같아 내생각에는 위와 같이 별다른 기여가 없더라도 응용영역은 만들어두는것이 좋다고 생각한다.