애플리케이션은 대부분 웹 인터페이스 같은 것을 제공한다. 웹 브라우저를 통해 상호작용할 수 있는 UI나 다른 시스템에서 우리 애플리케이션으로 호출하는 방식으로 상호작용하는 HTTP API가 여기 해당한다.
웹 어댑터는 ‘주도하는’ 혹은 ‘인커밍’ 어댑터다. 외부로부터 요청을 받아 애플리케이션 코어를 호출하고 무슨 일을 해야 할지 알려준다. 이때 제어 흐름은 웹 어댑터에 있는 컨트롤러에서 애플리케이션 계층에 있는 서비스로 흐른다.
인커밍 어댑터는 애플리케이션 서비스에 의해 구현된 인터페이스 전용 포트를 통해 애플리케이션 계층과 통신한다.
애플리케이션 계층은 웹 어댑터가 통신할 수 있는 특정 포트를 제공한다. 서비스는 이 포트를 구현하고, 웹 어댑터는 이 포트를 호출할 수 있다.
자세히 살펴보면 의존성 역전 원칙이 적용된 것을 발경할 수 있다. 제어 흐름이 왼쪽에서 오른쪽으로 흐르기 때문에 웹 어댑터가 유스케이스를 직접 호출할 수 있다.
어댑터와 유스케이스 사이에 또 다른 간접 계층을 넣는 이유는, 애플리케이션 코어가 외부 세계와 통신할 수 있는 곳에 대한 명세가 포트이기 때문이다. 포트를 적절한 곳에 위치시키면 외부와 어떤 통신이 일어나고 있는지 정확히 알 수 있고, 이는 레거시 코드를 다루는 유지보수 엔지니어에게는 무척 소중한 정보다.
<aside> ❓
만약 웹 소켓을 통해 실시간 데이터를 사용자의 브라우저로 보낸다고 가정해보자. 애플리케이션 코어에서는 이런 실시간 데이터를 어떻게 웹 어댑터로 보내고, 웹 어댑터는 이 데이터를 어떻게 사용자의 브라우저로 전송하는 것일까?
</aside>
이 시나리오에서는 반드시 포트가 필요하다. 포트는 웹 어댑터에서 구현하고 애플리케이션 코어에서 호출해야 한다.
만약 애플리케이션이 웹 어댑터에 능동적으로 알림을 줘야 한다면 올바른 방향으로 유지하기 위해 아웃고잉 포트를 통과해야 한다.
엄밀히 말하자면 이 포트는 아웃고잉 포트이기 때문에 이제 웹 어댑터는 인커밍 어댑터인 동시에 아웃고잉 어댑터가 된다. 한 어댑터가 동시에 두 가지 역할을 하지 못할 이유는 없다.
<aside> ❓
애플리케이션이 REST API를 제공한다고 했을 때, 웹 어댑터의 책임은 어디서부터 어디까지일까?
</aside>
웹 어댑터의 역할