「도메인 주도 개발 시작하기」6장 응용 서비스와 표현 영역

🎈 6.1. 표현 영역과 응용 영역

사용자 -> 표현 영역 -> 응용 영역 -> 도메인 영역

 

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

응용 영역은 실제 사용하자 원하는 기능을 제공함.

 

사용자와 상호작용은 표현 영역이 처리하기 때문에, 응용 서비스는 표현 영영에 의존하지 않음.

응용 영역은 사용자가 웹 브라우저를 사용하는지 REST API를 호출하는지, TCP 소켓을 사용하는지 알 필요가 없음. 

 

🎈 6.2. 응용 서비스의 역할

응용 서비스는 사용자가 요청한 기능을 실행함. 이를 위해 리포지터리에서 도메인 객체를 가져와 사용한다. 

 

응용 서비스의 구조

public Result doSomeFunc(SomeReq req){
	//1. 리포지터리에서 애그리거트를 구한다.
    SomeAgg agg = someAggRepository.findById(req.getId());
    checkNull(agg);
    
    //2. 애그리거트의 도메인 기능을 실행한다.
    agg.doFunc(req.getValue());
    
    //3. 결과를 리턴한다.
    return createSuccessResult(agg);
}

 

새로운 애그리거트를 생성하는 응용 서비스의 구조

public Result doSomeCreation(CreateSomeReq req){
	//1. 데이터 중복 등 유효한지 검사
    validate(req);
    
    //2. 애그리거트 생성
    SomeAgg newAgg = createSome(req);
    
    //3. 리포지터리에 애그리거트를 저장
    someAggRepository.save(newAgg);
    
    //4. 결과를 리턴
    return createSuccessResult(newAgg);
}

 

응용 서비스는 트랜잭션 처리도 담당한다. 트랜잭션 범위에서 응용 서비스를 실행해야 한다. 

 

 

6.2.1. 도메인 로직 넣지 않기

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

1. 코드의 응집성이 떨어짐.

도메인 데이터와 그 데이터를 조작하는 도메인 로직이 한 영역에 위치하지 않고 서로 다른 영역에 위치한다는 것은 도메인 로직을 파악하기 위해 여러 영역을 분석해야 한다는 것을 의미함.

2. 여러 응용 서비스에서 동일한 도메인 로직을 구현할 가능성이 높아짐. 

 

 

🎈 6.3. 응용 서비스의 구현

6.3.1. 응용 서비스의 크기

- 한 응용 서비스 클래스에 회원 도메인의 모든 기능 구현하는 방법

   동일하나 로직을 위한 코드 중복을 제거하기 쉽다는 장점, 서비스 클래스의 크기가 커진다는 단점. 

- 구분되는 기능 별로 서비스 클래스를 구현하는 방법

   클래스 개수 많아지지만 코드 품질을 일정 수준으로 유지하는 데 도움이 됨.

   동일한 로직을 구현할 경우 별도 클래스에 로직을 구현해서 코드 중복을 방지.

 

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

응용 서비스를 구현할 때 인터페이스가 필요한가?

인터페이스가 명확하게 필요하기 전까지는 응용 서비스에 대한 인터페이스를 작성하는 것이 좋은 선택이라고 볼 수는 없다. 

테스트 주도 개발을 즐겨 한다면 인트페이스를 이용해서 컨트롤러의 구현을 완성해 나갈 수 있다. 

 

6.3.3. 메서드 파라미터와 값 리턴

6.3.4. 표현 영역에 의존하지 않기

응용 서비스의 파라미터 타입을 표현 영역과 관련된 타입을 사용하면 안 된다. 

예를 들어 HttpServletRequest나 HttpSession을 응용 서비스에 파라미터로 전달하면 안 됨.

6.3.5. 트랜잭션 처리

@Transactional이 적용된 메서드가 RuntimeException을 발생시키면 트랜잭션을 롤백하고 그렇지 않으면 커밋하므로 이 규칙에 따라 코드를 작성하면 트랜잭션 처리 코드를 간결하게 유지할 수 있다. 

 

🎈 6.4. 표현 영역

책임

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

2. 사용자의 요청을 알맞은 응용 서비스에 전달하고 결과를 사용자에게 제공

3. 사용자의 세션을 관리

 

//프레임워크 제공 기능 사용하면 파라미터를 ChangePasswordRequest chPwdReq으로 자바 객체를 바로 생성할 수도 있음
@PostMapping()
public String changePassword(HttpServletRequest request, Errors errors){
	//표현 영역은 사용자 요청을 응용 서비스가 요구하는 형식으로 변환함.
    String curPw = request.getParameter("curPw");
    String newPw = request.getParameter("newPw");
    String memberId = SecurityContext.getAuthentication().getId();
    ChangePasswordRequest chPwdReq = 
    	new ChangePasswordRequest(memberId, curPw, newPw);
        
    try{
    	//응용 서비스 실행
        changePasswordService.changePassword(chPwdReq);
        return successView;
    }catch(BacPasswordException | NoMemberException ex){
    	//응용 서비스의 처리 결과를 알맞은 응답으로 변환
        errors.reject("idPasswordNotMatch");
        return formView;
    }
}

 

+ 서비스의 실행 결과를 사용자에게 알맞은 형식으로 제공하는 것도 표현 영역의 몫

+ 사용자의 연결 상태인 세션 관리

 

🎈 6.5. 값 검증

원칙적으로 모든 값에 대한 검증은 응용 서비스에서 처리.

 

사용자가 여러 값을 입력해야 할 때, 응용 서비스에서 에러 처리를 해버리면 첫 번재 값이 올바르지 않아 익셉션이 발생하면 나머지 항목에 대해서는 검사하지 않게 됨. -> 잘못된 모든 값을 확인할 수 있도록 하는 방법.

@Transactional
public OrderNo placeOrder(OrderRequest orderRequest){
	List<ValidationError> errors = new ArrayList<>();
    if(orderRequest ==  null){
    	errors.add(ValidationError.of("empty");
    } else {
    	if(orderRequest.getOrdererMemberId() == null)
        	errors.add(ValidationError.of("ordererMemberId", "empty"));
        if(orderRequest.getOrderProducts() == null)
        	errors.add(ValidationError.of("orderProducts", "empty"));
        if(orderRequest.getOrderProducts().isEmpty())
        	errors.add(ValidationError.of("orderProducts", "empty"));
    }
    //응용 서비스가 입력 오류를 하나의 익셉션으로 모아서 발생
    if(!errors.isEmpty()) throw new ValidationErrorException(errors);
    ...
}

 

표현 영역에서 필수 값과 값의 형식을 검사하면 실질적으로 응용 서비스는 id 중복 여부와 같은 논리적 오류만 검사하면 된다.

 

🎈 6.6. 권한 검사

보통 다음 세 곳에서 권한 검사를 수행할 수 있다. 

- 표현 영역

- 응용 서비스

- 도메인

 

1. 표현 영역에서 할 수 있는 기본적인 검사는 인증된 사용자인지 아닌지 검사하는 것.

url을 처리하는 컨트롤러에 웹 요청을 전달하기 전에 인증 여부를 검사해서 인증된 사용자의 웹 요청만 컨트롤러에 전달한다, 인증된 사용자 아닐 경우 로그인 화면으로 리다이렉트한다. 

-> 서블릿 필터 Servlet Filter. 스프링 시큐리티도 이와 유사한 방식으로 필터를 이용해 인증 정보 생성하고 웹 접근을 제어.

 

2. URL 만으로 접근 제어를 할 수 없는 경우 응용 서비스에서 메서드 단위로 권한 검사.

예를 들면 스프링 시큐리티의 @PreAuthorize 애너테이션.

 

3. 개별 도메인 객체 단위로 권한 검사. 

 

이해도가 높지 않아 프레임워크 확장을 원하는 수준으로 할 수 없다면 프레임워크를 사용하는 대신 도메인에 맞는 권한 검사 기능을 직접 구현하는 것이 코드 유지 보수에 유리하다. 

 

🎈 6.7. 조회 전용 기능과 응용 서비스

조회를 위한 응용 서비스가 단지 조회 전용 기능을 실행하는 코드밖에 없다면 응용 서비스를 생략해도 무방함.