- 웹 어댑터는 ‘주도하는’ 혹은 ‘인커밍’ 어댑터다. 외부로부터 요청을 받아 애플리케이션 코어를 호출하고 무슨 일을 해야 할지 알려줌
- 어플리케이션 계층은 웹 어댑터가 통신할 수 있는 특정 포트를 제공함
- 서비스는 이 포트를 구현하고, 웹 어댑터는 이 포트를 호출할 수 있다.
웹 어댑터의 책임
- HTTP 요청을 자바 객체로 매핑
- 권한 검사
- 입력 유효성 검증
- 유스케이스 입력 모델에서 했던 유효성 검증을 똑같이 구현해야 하는 것이 아닌, 웹 어댑터의 입력 모델을 유스케이스의 입력 모델로 변환할 수 있다는 것을 검증
- 입력을 유스케이스의 입력 모델로 매핑
- 유스케이스 호출
- 유스케이스의 출력을 HTTP로 매핑
- HTTP 응답을 반환
- 웹 어댑터는 책임이 좀 많기는 하지만 이 책임들은 어플리케이션 계층이 신경 쓰면 안되는 것들이긴 함
- HTTP와 관련된 것은 애플리케이션 계층으로 침투해서는 안 된다. 우리가 바깥 계층에서 HTTP를 다루고 있다는 것을 애플리케이션 코어가 알게 되면 HTTP를 사용하지 않는 또 다른 인커밍 어댑터의 요청에 대해 동일한 도메인 로직을 수행할 수 있는 선택지를 잃게 됨
컨트롤러 나누기
- 클래스들이 같은 소속이라는 것을 표현하기 위해 같은 패키지 수준에 놓고
- 컨트롤러 개수는 너무 적은 것보다는 너무 많은 게 나음
- 각 컨트롤러가 가능한 한 좁고 다른 컨트롤러와 가능한 한 적게 공유하는 웹 어댑터 조각을 구현해야 함
- 모든 연산을 단일 컨트롤러에 넣으면 데이터 구조의 재활용을 촉진함
- 각 연산에 대해 가급적 별도의 패키지 안에 별도의 컨트롤러를 만드는 방식 선호한다고 함
- 또한 메서드와 클래스명은 유스케이스를 최대한 반영해서 지어야 함
- 전용 모델 클래스들도 컨트롤러 패키지에 대해 package-private으로 선언할 수 있기에 다른 곳에서 실수로 재사용될 일이 없음
웹 컨트롤러를 나눌 때는 모델을 공유하지 않는 여러 작은 클래스들을 만드는 것을 두려워 해서는 안된다. 작은 클래스들은 더 파악하기 쉽고, 더 테스트하기 쉬우며, 동시 작업을 지원한다. 이렇게 세분화된 컨트롤러를 만드는 것은 처음에는 조금 더 공수가 들겠지만 유지보수하는 동안에는 분명히 빛을 발할 것이다.