TIL

05. 웹 어댑터 구현하기

우리가 목표로 하는 아키텍처에서 외부 세계와의 모든 커뮤니케이션은 어댑터를 통해 이뤄진다.

의존성 역전

• 웹 어댑터는 ‘주도하는’ 혹은 ‘인커밍’ 어댑터다.
  • 외부에서 요청을 받아 애플리케이션 코어를 호출
  • 제어 흐름은 웹 어댑터에서 애플리케이션 계층으로
• 의존성 역전 원칙이 적용되어 유스케이스를 직접 호출하는 것이 아닌 포트 인터페이스를 통해 애플리케이션 계층을 호출한다.
• 제어 흐름이 웹 → 애플리케이션 계층이기 때문에 포트를 생략할 수도 있지만 간접 계층을 꼭 넣어야 할까?
  • 애플리케이션 코어가 외부 세계와 통신할 수 있는 곳에 대한 명세가 포트
  • 포트를 통해 애플리케이션이 외부 세계와 어떤 통신이 일어나는지 정확히 알 수 없기에 유지보수 엔지니어에게는 무척 소중한 정보다.

웹 어댑터의 책임

• REST API를 제공하는 애플리케이션에서 웹 어댑터의 책임
  • HTTP 요청을 자바 객체로 매핑
  • 권한 검사
  • 입력 유효성 검증
  • 입력을 유스케이스 입력 모델로 매핑
  • 유스케이스 호출
  • 유스케이스 출력을 HTTP로 매핑
  • HTTP 응답을 반환
• 웹 어댑터에서도 입력 유효성을 검증하지만 애플리케이션 계층에서의 유효성 검증과는 다르다.
  • 웹 어댑터의 입력 모델을 유스케이스 입력 모델로 변환해야 하는데 이 변환을 방해하는 모든 것이 유효성 검증 에러에 해당한다.
• 웹 어댑터에 책임이 많기는 하지만 애플리케이션 계층이 신경 쓰면 안 되는 것들이기도 하다.

컨트롤러 나누기

• 웹 어댑터는 한 개 이상의 클래스로 구성해도 된다.
  • 모든 요청에 응답할 수 있는 하나의 컨트롤러만 만들 필요는 없다.
  • 다만 여러 컨트롤러를 같은 패키지 수준에 놓아야 한다.
  • 컨트롤러 개수는 너무 적은 것보단 너무 많은 게 낫다.
  • 각 컨트롤러가 가능한 좁고 다른 컨트롤러와 공유하는게 적은 어댑터 조각을 구현해야 한다.
• 각 유스케이스에 대해 가급적 별도 패키지 안에 별도의 컨트롤러로 구현하는 방식을 선호
  • 각 메서드와 클래스명은 유스케이스를 최대한 반영해서 지어야 한다.
  • SendMoneyController 예제 코드
• 이렇게 각 컨트롤러로 나누는 스타일의 또 다른 장점은 동시 작업이 쉬워진다.
  • 각 개발자가 각 유스케이스를 작업할 때 충돌을 피할 수 있다.