05_implementing_a_web_adapter.md

05. 웹 어댑터 구현하기

1. 웹 어댑터의 책임

• 웹 어댑터

  • '주도하는' 혹은 '인커밍' 어댑터
  • 외부로부터 요청을 받아 애플리케이션 코드를 호출하고 무슨 일을 해야할지 알려준다.
  • 이때 제어의 흐름은 컨트롤러에서 애플리케이션 계층의 서비스로 흐른다.

• 책임: 요청을 받아 적절한 유스케이스를 호출하고 출력을 받환하는 것이 주된 책임

  1. HTTP 요청을 자바 객체로 매핑
  2. 권한 검사
  3. 입력 유효성 검증
  4. 입력을 유스케이스의 일벽 모델로 매핑
  5. 유스케이스 호출
  6. 유스케이스의 출력을 HTTP로 매핑
  7. HTTP 응답을 반환

• 여기서 유스케이스 계층에서 수행했던 입력 유효성 검증이 다시 등장한다. 책에서는 다음과 같이 설명한다.

  유스케이스 입력 모델은 유스케이스의 맥락에서 유효한 입력만 허용해야 한다. 그러나 여기서는 웹 어댑터의 입력 모델에 대해 이야기하고 있는 것이다. 유스케이스의 입력 모델과는 구조나 의미가 완전히 다를 수 있으므로 또다른 유효성 검증을 수행해야 한다.
  유스케이스 입력 모델에서 했던 유효성 검증을 똑같이 웹 어댑터에서 구현해야 하는 것은 아니다. 대신, 웹 어댑터의 입력 모델을 유스케이스의 입력 모델로 변환할 수 있다는 것을 검증해야 한다. 이 변환을 방해하는 모든 것이 유효성 검증 에러이다.

• 사실 이 부분이 처음에는 이해가 잘 안되었다. 유스케이스의 그것과 어떤 차이가 있을까?

• 그러다 어느 정도 이해된 것은, 아마도 데이터 형식에 대한 입력 유효성 검증이 아닐까 싶다. 입력 모델 간의 변환을 방해하는 요소는 바로 그런 부분이기 때문이다.

• 예를 들어, 유스케이스 입력 모델이 숫자 형식인 12345를 받는다고 하자. 그런데 웹 어댑터의 입력 모델에서 "ABCDE"의 문자가 온다면 이는 웹 어댑터에서 수행할 수 있는 입력 유효성 검증이 될 것이다.

• 이러한 웹 어댑터의 책임이 많은 이유를 책에서는 애플리케이션 계층을 보호하기 위함이라 설명한다.

  ... 이 책임들은 애플리케이션 계층이 신경 쓰면 안되는 것들이기도 하다. ... 우리가 바깥 계층에서 HTTP를 다루고 있다는 것을 애플리케이션 코어가 알게 되면, HTTP를 사용하지 않는 또 다른 인커밍 어댑터의 요청에 대해 동일한 도메인 로직을 수행할 수 있는 선택지를 잃게 된다.

• 그러면서 좋은 가이드라인을 소개한다.

  웹 어댑터와 애플리케이션 계층 간의 이 같은 경계는 웹 계층에서부터 개발을 시작하는 대신 도메인과 애플리케이션 계층부터 개발하기 시작하면 자연스럽게 생긴다. 특정 인커밍 어댑터를 생각할 필요 없이 유스케이스를 먼저 구현하면 경계를 흐리게 만들 유혹에 빠지지 않을 수 있다.

  2. 컨트롤러 나누기

  • 책에서는 처음에 도메인에 대한 컨트롤러를 생성하지만 (AccountController), 길어지는 코드, 커맨드의 중복 사용 등을 이유로 지양하길 권한다.
  • 대신, 유스케이스를 최대한 반영한 별도의 패키지를 갖는 별도의 컨트롤러를 생성하길 권한다. (SendMoneyController)
  • 이러면 컨트롤러의 입력 커맨드를 package-private하게 만들 수 있어, 최대한 결합을 제거할 수 있는 장점도 있다.
  • 이 책에서 자주 등장하는 클래스명 패턴인데, 바로 동사형 클래스명을 사용한다는 점이다. 이는 유스케이스를 분명하게 하여 해당 클래스가 어떤 역할을 하는지 명확하게 알려주는 장점이 있다.
  • 책은 마지막으로, 여러 작은 클래스로 만드는 것을 두려워해서는 안된다고 말한다. 이는 더 파악하기 쉽고, 테스트하기 쉬우며, 동시 작업을 지원(충돌방지) 한다는 장점을 갖고 있다.