> For the complete documentation index, see [llms.txt](https://develop-footprint.gitbook.io/o/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://develop-footprint.gitbook.io/o/programming/clean-architecture/clean-book/3.md).

# 웹 어댑터

> 💡 웹 인터페이스를 제공하는 어댑터

### 의존성 역전

* 외부로부터 요청을 받아 코어를 호출하고 무슨일을 해야할 지 알려준다.
* 제어의 흐름은 컨트롤러에서 서비스(유스케이스)로 흐른다.

#### 포트 인터페이스가 필요한 이유

* 포트는 애플리케이션 코어와 외부 세계가 통신할 수 있는 곳에 대한 명세이다.
* 외부와 어떤 통신이 일어나고 있는지 정확히 알 수 있어 개발자에게 편리하다.
* 물론 [직접 서비스를 호출하는 방법](/o/programming/clean-architecture/clean-book/9.md)을 사용할 수도 있다.
* 실시간 데이터를 웹소켓을 통해 웹 어댑터로 보내 사용자의 브라우저에 전송하는 경우 어떻게 구현할까?
  * 웹 어댑터에서 아웃고잉 포트를 구현하고 애플리케이션 코어에서 호출해야 한다.
  * 이렇게 될 경우 웹 어댑터는 인커밍 어댑터인 동시에 아웃고잉 어댑터가 된다.

### 웹 어댑터의 책임

> 💡 7가지 책임
>
> * HTTP 요청을 자바 객체로 매핑
> * 권한 검사 (인증과 권한 부여 수행)
> * 입력 유효성 검증
>   * 웹 어댑터의 입력 모델을 유스케이스의 입력 모델로 변환할 수 있음을 검증하는 작업
>   * 이 변환이 방해되면 유효성 검증 에러 발생
> * 입력을 유스케이스의 입력 모델로 매핑
> * 유스케이스 호출
> * 유스케이스 출력을 HTTP로 매핑
> * HTTP 응답 반환

* HTTP와 관련된 내용은 애플리케이션 계층으로 침투하게 해서는 안된다.
* 잘 분리한다면, HTTP를 사용하지 않는 또다른 인커밍 어댑터의 요청에 동일한 로직을 수행할 수 있다.

> 좋은 아키텍처에서는 선택의 여지를 남겨둔다는 것!

* 도메인과 애플리케이션 계층부터 먼저 개발하기 시작하면 (유스케이스를 먼저 구현하면) 자연스럽게 어댑터와 유스케이스 간의 경계가 생긴다.

### 컨트롤러 나누기

* 각 컨트롤러는 가능한 한 좁고 다른 컨트롤러와 적게 공유하는 웹 어댑터 조각을 구현해야 한다.
* 클래스마다 코드는 적을수록 좋다.
* 가급적이면 별도 패키지 안에 별도 컨트롤러를 만드는 방식
* 메서드와 클래스명은 유스케이스를 최대한 반영해 지어야 한다.
* 컨트롤러 자체의 전용 모델 혹은 원시 코드를 입력받을 수 있다.
* 컨트롤러 패키지에 대해 private으로 선언해 다른 곳에서 재사용하지 못하게 할 수 있다.
* 필요없는 필드가 담긴 클래스를 사용하기보다는 새로 모델을 만들어 사용하자.
* 무작정 create, update, delete만을 사용하기보다는 한번 더 의미를 생각해보고 변수명을 짓도록 하자.