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

일단 해볼게·2025년 8월 10일
0

book

목록 보기
23/31

6.1 표현 영역과 응용 영역

  • 표현 영역에서 request를 받는다. → 응용 영역에서 request의 데이터를 추출해서 실행 결과를 반환한다.
    • 응용 영역은 표현 영역에 의존하지 않는다.

6.2 응용 서비스의 역할

  • 사용자의 요청을 처리하기 위해 리포지터리에서 도메인 객체를 가져와 사용
  • 트랜잭션 처리도 담당
    • 데이터 일관성 유지
  • 도메인 로직을 응용 서비스에 넣지 않기
    • 문제
      • 코드의 응집성이 떨어진다.
      • 여러 응용 서비스에서 동일한 도메인 로직을 구현할 가능성이 높아진다.
        • 실제로 여러 응용 서비스에서 동일한 도메인 로직을 구현한 코드를 자주 봐서 공감된다.

6.3 응용 서비스의 구현

  • 표현 영역과 도메인 영역을 연결하는 매개체
    • facade와 같은 역할
  • 구현 방식
    • 한 응용 서비스 클래스에 회원 도메인 모든 기능 구현
      • 장점
        • 동일 로직에 대한 코드 중복 제거 가능
      • 단점
        • 서비스 클래스의 크기가 커진다.
        • 한 클래스에 코드가 모여 분리를 하지 않아 코드 품질 저하 가능
    • 구분되는 기능별로 응용 서비스 클래스를 따로 구현
      • 한 응용 서비스 클래스에서 한개 내지 2~3개의 기능을 구현한다.
      • 장점
        • 코드 품질 유지
      • 단점
        • 클래스의 개수가 많아진다.
  • 인터페이스가 필요한 상황
    • 구현 클래스가 여러 개인 경우
      • 런타임에 구현 객체를 교체해야할 때
        • 전략패턴을 이용해 파라미터에 따라 response를 변경해야하는 경우에 겪어봤다.
    • 인터페이스가 명확하게 필요하기 전까지는 응용 서비스에 대한 인터페이스를 작성하는 것이 좋은 선택이라고 볼 수 없다.
    • TDD를 한다면?
      • 표현 영역을 먼저 개발할 때
        • 미리 응용 서비스를 구현할 수 없으므로 인터페이스 먼저 작성
          • 응용 서비스의 인터페이스를 이용해서 컨트롤러의 구현을 완성해 나갈 수 있다.
      • 도메인 영역이나 응용 영역의 개발을 먼저 한다면?
        • Mockito 같은 테스트 대역 객체로 대체
  • 응용 서비스가 제공하는 메서드는 도메인을 이용해서 사용자가 요구한 기능을 실행하는 데 필요한 값을 파라미터로 전달 받아야한다.
    • 개별 파라미터로 전달 or request dto 만들어서 전달
  • 응용 서비스가 리턴한 값
    • 식별자 리턴
    • modelAttribute로 객체 리턴
      • 도메인 로직 실행을 표현 영역에서 사용할 수 있게 되어 코드 응집도가 낮아진다.
        • 필요한 데이터만 리턴
  • 응용 서비스에서 표현 영역에 의존하지 않기
    • HttpServletRequest, HttpSession 등
    • 응용 서비스만 단독으로 테스트하기 어려워진다.
  • 응용 서비스 : 트랜잭션 관리

6.4 표현 영역

  • 표현 영역의 책임

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

6.5 값 검증

  • 표현 영역, 응용 서비스에서 값 검증 가능
    • 원칙적으로는 응용 서비스에서 처리
    • 표현 영역에서 한다면 번잡한 코드를 작성해야한다.
  • 응용 서비스에서 각 값이 유효한지 확인하는 목적으로 exception을 사용한다면?
    • 한 개의 항목에 대해 검증하기 때문에 사용자는 같은 폼에 값을 여러 번 입력할 가능성 존재
  • error들을 모아서 반환하면 뷰에서 사용할 형태로 변환
  • Validator 인터페이스를 구현한 검증기를 따로 구현하면 간결하게 구현 가능
  • 응용 서비스를 사용하는 표현 영역의 코드가 한 곳일 때 검증하는 방법(예시)
    • 표현 영역 : 필수 값, 값의 형식, 범위 등을 검증
    • 응용 서비스 : 데이터 존재 유무와 같은 논리적 오류 검증
  • 필자는 응용 서비스에서 값 검증
    • 표현 영역에서 작성하는 것보다 작성할 코드가 늘어나지만, 응용 서비스의 완성도가 높아지는 장점 존재

6.6 권한 검사

  • 권한 복잡도

    • 인증 여부 검사
    • 관리자 여부 검사
  • 권한 검사 수행하는 영역

    • 표현 영역
      • 인증된 사용자인지 검사

        • 예시> 회원 정보 변경
      • 서블릿 필터에서 인증 정보 생성 및 인증 여부 검사

    • 응용 서비스
      • URL만으로 접근 제어 불가능한 경우 응용 서비스에서 메서드 단위로 권한 검사
    • 도메인

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

  • 서비스에서 수행하는 추가 로직 X
  • 단일 쿼리만 실행하는 조회 전용 기능이어서 트랜잭션 불필요
  • 응용 서비스가 불필요하여 표현 영역에서 바로 조회 전용 기능 호출해도 무방
profile
시도하고 More Do하는 백엔드 개발자입니다.

0개의 댓글