CH05 웹 어댑터 구현하기

웹 어댑터 의존성 역전

계속해서 DIP 가 강조되고 있다. 그만큼 헥사고날 아키텍처에서 DIP 는 핵심적인 개념이다.

서비스가 컨트롤러에 의존하지 않도록 어플리케이션에서 인터페이스로 인커밍 포트를 구현하고 컨트롤러는 이와 소통한다. 인커밍 포트는 곧 유스케이스라고 할 수 있는데 어플리케이션 코어가 외부 세계와 통신할 수 있는 곳에 대한 명세가 곧 이 포트이다.

포트의 위치와 명세를 통해서 어떤 기능으로 인해 어떤 부분에서 어플리케이션 코어와 외부가 맞닿아 있고 어떻게 통신하는지 알 수 있다.

웹 어댑터에서의 validation

책에서 구분지어 말하고 있는 부분이 있다. Command, Query 객체의 생성자에서 기본적인 입력 유효성 검사를 하되 웹 어댑터에서도 유효성 검사를 또 해라는 것이다.

여기서 해야할 유효성 검사의 기준은 '입력 값이 유스케이스의 입력 모델로 변환할 수 있다'라는 것을 만족시키는가 이다.

컨트롤러 나누기

책에서는 컨트롤러 역시 기능별로 나누길 권장한다. 여러 이유가 있지만 일단 분업하기가 용이하고(코드 충돌이 나지 않으니까) 구조적으로 각 기능의 위치를 쉽게 파악할 수 있어서이다. 이렇게 되면 거의 API 하나에 컨트롤러가 하나가 나올 것 같은데, 이게 실무에서 가능할 지 모르겠다. 아니면 성격별로 API n개에 컨트롤러 하나겠지만 n개가 적은 수가 될 것 같다.

안될것도 없는데 아무래도 팀 내 협의가 이뤄져야할 것이다. 개인적인 생각에는 나누는 것도 좋은 것 같다. 왜냐면 넓은 컨트롤러를 쭉 보면서 원하는 기능을 찾을 시간을 아껴줄 수 있고 컨트롤러를 일일이 쪼갠 구조 자체가 '표현력이 강한' 구조가 될 수 있기 때문이다.

근본적으로 웹 어댑터와 어플리케이션의 구분을 다시 생각해보자

당연한 이야기지만 정리를 다시 해보자. 웹 어댑터에는 그 어떤 도메인 로직도 들어가 있지 않아야 한다. 그리고 어플리케이션에서는 HTTP 에 대해서 하나도 몰라야 한다. 어플리케이션은 이게 서버로 통신할 프로그램인지 아닌지 그 어떤 것도 몰라야 한다.