도메인 주도 개발 시작하기 - 6장

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

 

6.1

응용 영역과 표현 영역이 사용자와 도메인을 연결해 주는 매개체 역할

표현 영역은 사용자의 요청을 해석

URL, 요청 파라미터, 쿠키, 헤더 등을 이용해서 판별 기능을 제공하는 응용서비스를 실행

실제 사용자가 원하는 기능을 제공하는 것은 응용 영역에 위치한 서비스다.

표현 영역은 응용 서비스가 요구하는 방식으로 변환

응용 서비스는 표현 영역에 의존하지 않는다.

단지 필요한 입력 값을 받고 결과만 리턴

 

6.2

응용서비스는 리포지터리에서 도메인 객체를 가져와 사용

응용 서비스는 도메인 영역과 표현 영역을 연결해 주는 창구

응용 서비스가 복잡하다면 도메인 로직의 일부를 구현하고 있을 가능성이 높다.

응용 서비스는 도메인의 상태 변경을 트랜잭션으로 처리

DB에 반영하는 도중 문제가 발생 -> 데이터 일관성이 깨지게 된다. 트랜잭션 범위에서 서비스를 실행해야 한다.

 

도메인의 핵심로직은 응용서비스에서 로직을 궇ㄴ하면 안된다.

도메인 로직을 도메인 영역과 응용 서비스에 분산해서 구현하면 코드 품질에 문제가 발생한다.

첫 번째 문제는 코드의 응집성이 떨어진다.

두 번째는 문제는 여러 응용 서비스에서 동일한 도메인 로직을 구현할 가능성이높아진다.

소프트웨어의 가치 중 변경 용이성, 중복을 줄이고 응집도를 높여야 한다.

 

6.3

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

한 클래스에서 모두 구현

동일한 로직을 위한 코드 중복을 제거하기 쉽다는 장점, 코드의 크기가 커진다는게 단점

코드를 얽히게 만들어 코드 품질을 낮추는 결과를 초래

기능별로 서비스 클래스를 구현하는 방식

동일한 로직을 구현할 경우 여러 클래스에 중복해서 동일한 코드를 구현할 가능성이 있다.

필자는 클래스마다 구분되는 역할을 갖는 것을 선호

 

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

인터페이스가 필요한 몇 가지 상황이 있는데

• 구현 클래스가 여러개
• TDD

Mockito 같은 테스트 도구는 응용 서비스에 대한 인터페이스 필요성을 약화시킨다.

 

응용서비스가 제공하는 메서드는 도메인을 이용해서 사용자가 요구한 기능을 실행하는 데 필요한 값을 파라미터로 전달받아야 한다.

요청 파라미터가 두 개 이상 존재하면 별도 클래스를 사용하는 것이 편리하다.

응용 서비스의 결과를 포현 영역에서 사용해야 하면 응용 서비스 메서드의 결과로 필요한 데이터를 리턴

응용 서비스에서 에그리거트 자체를 리턴하면 로딩은 편할 수 있지만, 도메인 로직 실행을 응용 서비스와 표현 영역 두 곳에서 할 수 있게 된다.

응집도를 낮추는 원인이 된다.

응용서비스는 표현 영역에서 필요한 데이터만 리턴하는 것이 기능 실행 로직의 응집도를 높이는 확실한 방법이다.

 

표현 영역과 관련된 타입을 사용하면 안된다. 표현 영역에서만 사용돼야하는 타입 ( HttpServerletRequest, HttpSession ) 이 응용 서비스에 파라미터로 전달되면 안된다.

표현 영역에서 사용돼야 하는 타입을 응용 서비스에서 사용하므로 유지비용이 증대되는 문제를 발생시키지 않으려면 서비스 메서드의 파라미터와 리턴 타입으로 표현 영역의 구현 기술을 사용하지 않아야 한다.

 

프레임워크가 제공하는 트랜잭션 기능을 적극 사용하는 것이 좋다.

 

6.4

표현 영역의 첫 번째  책임은 사용자가 시스템을 사용할 수 있도록 알맞은 흐름을 제공하는 것이다.

MVC 프레임워크는 HTTP 요청 파라미터로부터 자바 객체를 생성하는 기능을 지원하므로 이 기능을 사용하면 자가 객체를 손쉽게 생성할 수 있다.

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

 

6.5

값 검증은 표현 영역과 응용 서비스 두 곳에서 모두 수행할 수 있다. 원칙적으로 모든 값에 대한 검증은 응용 서비스에서 처리한다.

에러 메시지를 보여주기 위한 용도로 Error, BindingResult를 사용

에러 코드를 모아 하나의 익셉션으로 발생시키는 방법도 있다.

스프링에서 값 검증을 위한 Vaildator 인터페이스를 별도로 제공

응용 서비스에서 필요한 값 검증을 모두 처리하면 프레임워크가 제공하는 검증 기능을 사용할 때보다 작성할 코드가 늘어나는 불편함이 있지만 반대로 응용 서비스의 완성도가 높아지는 이점이 있다.

 

6.6

시큐리티 같은 프레임워크는 유연하고 확장 가능한 구조

보안 프레임워크는 세 곳에서  권한 검사를 할 수 있다.

• 표현 영역
• 응용 서비스
• 도메인

서블릿 필터에서 url 을 이용한 권한검사를 하기 좋다.

스프링 시큐리티는 AOP를 활용해서 애너테이션으로 서비스 메서드에 대한 권한 검사를 할 수 있는 기능을 제공한다.

도메인 객체 단위로 권한 검사를 하는 경우 복잡해진다. 직접 권한 검사 로직을 구현해야 한다.