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

응용 서비스와 표현 영역

응용 서비스 구현

응용 서비스의 역할

1. 도메인 객체간 흐름제어
2. 트랜젝션
3. 접근제어
4. 이밴트 처리

주의사항

도메인로직이 응용서비스에 분산하면 안된다.

• 코드의 응집성이 떨어짐
• 여러 응용 서비스에서 동일한 도메인 로직을 구현할 가능성이 높아진다

응용서비스의 크기

2가지 방법

1. 한 응용 서비스 클래스에 회원 도메인의 모든 기능 구현하기
   1. 장점 - 동일한 로직을 위한 코드 중복을 제거하기 쉬움
   2. 단점 - 코드 크기가 커지면 연관성이 적은 코드가 한 클래스에 함께 위치할 가능성이 높아지게 되는데 결과적으로 관련없는 코드가 뒤섞여 코드를 이해하는 데 방해가 됨
2. 구분되는 기능별로 응용 서비스 클래스를 따로 구현하기
   1. 공통로직을 service helper로 분리해서 여러 service코드에서 사용하도록 만듬

인터페이스를 작성하는 것이 좋은가?

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

• 팀에서 먼저 interface를 만들고 PR을 생성하는 것을 권장 받은적이 있음.
  • 클래스가 많아진다는 문제는 확실하게 있음.
  • 단점이 명확하지는 않은듯함.
• mockito
  • thenAnswer()
  • thenReturn()
  • thenThrow()

메서드 파라미터와 값 리턴

메서드 파라미터

p213 - @PostMapping에서 파라미터로 가져온 값을 application 계층이 알고있어도 무방한가?

HttpServletReqeust와 같은 클래스를 application 으로 전달하면 안됨

값 리턴

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

해결방법

1. 내부적으로 규칙을 정해서 presentation 계층에서는 사용하지 못하도록 한다.
   1. 장점 - application 계층이 presentation계층을 몰라도 상관없다. → 이게 왜 필요하지? → 도메인 계층에서는 응용계층이 어떻게 사용할지 몰라도 상관없도록 작업이 이루어져야함. → application계층은 presentation계층에서 어떻게 리턴하고싶은지 알아야함. (이건 왜?)
   2. 단점 - 규칙을 위반하는 사례를 대응 할 수 없음.
2. 표현영역에서 필요한 데이터만 application 계층에서 리턴하도록 한다.
   1. 장점 - 규칙을 위반 하는 사례를 만들지 않음? → 진실일까?

표현 영역의 역할

💡 표현영역은 Controller 를 포함한다. 그렇다면 message queue 에서 Consumer는 표현영역일까? 아니면 다른 영역일까?

책임 3가지

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

값 검증과 권한 검사

값 검증

• 표현영역 - 필수값, 값의 형식, 범위등을 검증한다.
• 응용서비스 - 데이터의 존재 유무와 같은 논리적 오류를 검증한다.

저자 : 요즘은 가능하면 응용 서비스에서 필수값 검증과 논리적 검증을 모두하는 편

권한 검사

chain of responsibility pattern을 사용하면 보다 간편하고 유지보수성 높은 코드를 작성할 수 있다.

조회의 경우 보다 간결하게

조회 응용 서비스 없이 호출해보자!

어색할 수 있지만 별다른 기여를 하지 못한다면 없애는것도 적절한 방향임.