웹 어댑터는 '주도하는' 혹은 '인커밍' 어댑터이며, 외부로부터 요청을 받아 애플리케이션을 호출하고 무슨 일을 해야할지 알려준다
애플리케이션 계층은 웹 어댑터가 동신할 수 있는 특정 포트를 제공한다 (interface)
왜 어댑터와 서비스 사이에 간접 계층(포트)을 넣어야 할까?
- 외부와 어떤 통신이 일어나고 있는지 정확히 알 수 있다 (유지보수 엔지니어에게 소중한 정보)
- 인커밍 포트를 생략하고 서비스를 직접 호출하는 지름길은? (11장에서 이야기한다)
반드시 포트가 필요한 Case
웹 소켓을 통한 실시간 데이터 통신
- 애플리케이션 서비스가 웹 어댑터에 능등적으로 알림을 주기위해 서비스는 어댑터로 데이터를 보내야한다
- 포트가 없다면 서비스는 어댑터를 알게되고 의존성이 발생한다
- 포트는 어댑터에 대한 의존성을 해결한다
PS. 웹 어댑터를 인커밍 어댑터로 정의하였지만, 인커밍,아웃고잉 어댑터를 언급하고 있음
- HTTP 요청을 자바 객체로 매핑
- 권한 검사
- 입력 유효성 검증
- 입력을 유스케이스의 입력 모델로 매핑
- 유스케이스 호출
- 유스케이스의 출력을 HTTP로 매핑
- HTTP 응답을 반환
웹어댑터의 유효성 검증이란 유스케이스 유효성 검증과 똑같이 구현하는 것이 아니다. 웹 어댑터의 입력 모델을 유스케이스의 입력 모델로 변환할 수 있다는 것을 검증해야 한다
웹어댑터와 애플리케이션 계층간 경계는 도메인과 애플리케이션 계층부터 개발하기 시작하면 자연스럽게 생긴다. 이는 특정 어댑터를 생각할 필요없기 때문에 경계를 흐리게 만드는 상황에 빠지지 않을 수 있다
모델을 공유하지 않은 여러 작은 클래스를 만드는 것을 두려워 하지 마라 각 컨트롤러가 가능한 좁고, 다른 컨트롤러와 가능한 한 적게 공유하는 웹 어댑터 조각을 구현해야 한다
- 가독성이 좋아진다
- 테스트 코드가 찾기 쉬어진다
- 전용 모델 클래스들은 private 선언할 수 있기 때문에 실수로 다른 곳에서 재사용되지 않는다 (?)
- 동시작업이 쉬어진다 (두 명의 개발자가 서로 다른 파일의 코드를 짜고 있기 떄문에)
- 공수가 더 많이 들겠지만 결국에는 유지보수성이 좋아진다