5장 웹 어댑터 구현하기

의존성 역전

인커밍 어댑터는 애플리케이션 서비스에 의해 구현된 인터페이스인 전용 포트를 통해 애플리케이션 계층과 통신한다.

여기서 왜 어댑터와 유스케이스 중간에 간접 계층을 넣어야 할까? 애플리케이션 코어가 외부 세계와 통신할 수 있는 곳에 대한 명세가 포트이기 때문이다.

→ 여기에 대한 이야기는 11장에서 더 하기로 한다.

웹 어댑터의 책임

1. Http 요청을 자바 객체로 매핑.
   1. 파라미터와 콘텐츠를 객체로 역직렬화 한다.
2. 권한 검사
3. 입력 유효성 검증
   1. 유스 케이스 입력 모델은 유스케이스의 맥락에서 유효한 입력만 허용해야 한다.
   2. 웹어댑터의 입력모델과 유스케이스의 입력 모델과는 또 다른 유효성 검증을 해야한다.
   3. 웹 어댑터의 입력 모델을 유스케이스의 입력 모델로 변환할 수 있다는 것을 검증해야 한다.
4. 입력을 유스케이스의 입력 모델로 매핑
5. 유스케이스 호출
6. 유스케이스의 출력을 HTTP로 매핑
7. HTTP 응답을 반환

컨트롤러 나누기

웹 어댑터는 한 개 이상의 클래스로 구성해도 된다. 각 컨트롤러가 가능한 한 좁고 다른 컨트롤ㄹ러와 가능한 한 적게 공유하는 웹 어댑터 조각을 구현해야 한다.

계좌 리소스와 관련된 모든 것이 하나의 클래스에 모여 있는 게 괜찮을까?

단점은 다음과 같다.

1. 클래스마다 코드는 적을 수록 좋다. 보기 힘들다.
2. 테스트 코드 파악이 어렵다. 특정 프로덕션 코드에 해당 하는 테스트 코드를 찾기 쉽게 만들어야 한다.
3. 데이터 구조의 재활용을 촉진한다. 즉, 계좌 리소스에서는 모든 연산에서 필요한 데이터를 담는 통 역할을 하게 되어, 불필요한 정보 포함이 생길 수 있다.

컨트롤러를 나누면 장점은 다음과 같다.

1. 컨트롤러에 맞는 모델을 새로 만들게 될 확률이 높다.
2. 컨트롤러 명과 서비스명에 대해서도 의미를 드러낼 수 있는 단어 채택을 할 수 있다.

유지 보수 가능한 소프트웨어를 만드는데 어떻게 도움이 될까?

웹 어댑터에서는 애플리케이션, 도메인 로직을 수행하지 않도록, HTTP 요청을 변환하는 역할 을 해야한다.

애플리케이션 계층은 Http 와 관련된 작업을 하면 안된다.