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