웹 어댑터 구현하기
Last updated
Last updated
인커밍 어댑터는 애플리케이션 서비스에 의해 구현된 인터페이스인 전용 포트를 통해 애플리케이션 계층과 통신한다.
외부로부터 요청을 받아 애플리케이션 코어를 호출하고 무슨 일을 해야 할지 알려준다. 이때 제어 흐름은 웹 어댑터에 있는 컨트롤러에서 애플리케이션 계층에 있는 서비스로 흐른다
애플리케이션 계층은 웹 어댑터가 통신할 수 있는 특정 포트를 제공하고, 서비스는 이 포트를 구현하고, 웹 어댑터는 이 포트를 호출할 수 있다.
애플리케이션 코어가 외부 세계와 통신할 수 있는 곳에 대한 명세가 포트이기 때문이다. 포트를 적절한 곳에 위치시키면 외부와 어떤 통신이 일어나고 있는지 정확히 알 수 있고, 이는 레거시 코드를 다루는 유지보수 엔지니어에게는 무척 소중한 정보다.
만약 애플리케이션이 웹 어댑터에 능동적으로 알림을 줘야 한다면 의존성을 올바른 방향으로 유지하기 위해 아웃고잉 포트를 통과해야 한다.
이 포트는 아웃고잉 포트이기 때문에 이제 웹 어댑터는 인커밍 어댑터인 동시에 아웃고잉 어댑터가 된다.
HTTP 요청을 자바 객체로 매핑
권한 검사
입력 유효성 검증
입력을 유스케이스의 입력 모델로 매핑
유스케이스 호출
유스케이스의 출력을 HTTP로 매핑
HTTP 응답을 반환
여기서는 웹 어댑터의 입력 모델에 대해 이야기를 하고 있는 것이다. 유스케이스의 입력 모델과는 구조나 의미가 완전히 다를 수 있으므로 또 다른 유효성 검증을 수행해야 한다.
대신, 웹 어댑터의 입력 모델을 유스케이스의 입력 모델로 변환할 수 있다는 것을 검증해야 한다.
클래스마다 코드는 적을 수록 좋다. 코드가 적으면 파악하는 것에 난이도가 낮아진다.
모든 연산을 단일 컨트롤러에 넣는 것이 데이터 구조의 재활용을 촉진한다는 데 있다. 그러나 이게 좋을까? 헷갈림만 가지게 될것이다. 따라서, 각 연산에 대해 가급적이면 별도의 패키지 안에 별도의 컨트롤러를 만들며 가급적 메서드와 클래스명은 유스케이스를 최대한 반영해서 지어야 한다. 서로 다른 연산에 대한 동시 작업이 쉬워진다는 것이 가장 큰 장점이다.
