‘만들면서 배우는 클린 아키텍처’ 기술 서적을 읽고 학습 내용을 정리하기 위한 목적의 TIL 포스팅입니다🙆♂️ 예제코드는 깃허브 레포지토리를 참고해주세요.
5장 - 웹 어댑터 구현하기
출처: https://jandari91.tistory.com/55
- 애플리케이션 계층은 웹 어댑터가 통신할 수 있는 특정 포트를 제공하고 웹 어댑터는 이 포트를 호출하고 서비스는 이 포트를 구현한다. 의존성 역전 원칙이 적용되었다.
출처: https://jandari91.tistory.com/55
- 왜 어댑터와 유스케이스 사이에 포트라는 간접 계층을 넣어야 할까? 애플리케이션 코어가 외부 세계와 통신할수 있는 곳에 대한 명세가 포트이고 외부와 어떤 통신이 일어나는지를 정확히 알 수 있기 떄문이다. (또한 유스케이스 로직을 순수하게 보호하기 위해서)
- 웹 소켓으로 실시간 데이터를 사용자의 브라우저로 보낸다할땐 반드시 포트가 필요하다. 아래 이미지와 같이 웹 어댑터에서 구현하고 애플리케이션 코어에서 호출해야 한다.
- 이 포트는 아웃고잉 포트이기에 이제 웹 어댑터는 인커밍 어댑터인 동시에 아웃고잉 어댑터가 된다. 한 어댑터가 두 가지 역할을 하지 못할 이유는 없다.
출처: https://jandari91.tistory.com/55
웹 어댑터의 책임
- HTTP 요청을 자바 객체로 매핑
- 권한검사
- 입력유효성 검증
- 입력을 유스케이스의 입력 모델로 매핑
- 유스케이스호출
- 유스케이스의 출력을 HTTP로 매핑
- HTTP 응답을 반환
- 입력유효성 검증은 유스케이스의 입력 모델과는 구조나 의미가 완전히 다를 수 있으므로 또 다른 유효성 검증을 수행해야 한다.
- 유스케이스 입력 모델에서 했던것과 똑같이 구현해야하는 것이 아니라 웹 어댑터의 입력 모델을 유스케이스 입력 모델로 변환할 수 있다는 것을 검증해야 한다. 이 변환을 방해하는 모든것이 유효성 검증에러다.
- 위 1부터 8까지의 과정중 하나라도 문제가 생기면 예외를 던지고, 웹 어댑터는 에러를 호출자에게 보여줄 메시지로 변환해야 한다.
- 하지만 이책임들은 애플리케이션 계층에서 신경쓰면 안되는 것들이기도 하다. HTTP와 관련된것은 애플리케이션 계층으로 침투해선 안된다. 우리가 바깥 계층에서 HTTP를 다루고 있다는 것을 애플리케이션 계층이 알게되면 HTTP를 사용하지 않는 또 다른 인커밍 어댑터는 애플리케이션 계층을 사용하지 못하게 된다. 좋은 아키텍처는 선택의 여지를 남겨둔다.
- 웹 어댑터와 애플리케이션 계층 간의 이 같은 경계는 도메인과 애플리케이션 계층부터 개발하기 시작하면 자연스레 생긴다.
- 특정 인커밍 어댑터를 생각할 필요 없이 유스케이스 먼저 구현하면 경계를 흐리게 만들 유혹에 빠지지 않을 수 있다.
컨트롤러 나누기
- 클래스마다 코드는 적을수록 좋다. 특정 프로덕션 코드에 해당하는 테스트 코드를 찾기도 쉽다.
- 저자는 각 연산에 대해 가급적이면 별도 패키지 안에 별도 컨트롤러를 만드는 방식을 선호한다.(ex.
SendMoneyController) - 또한 컨트롤러명과 서비스명에 대해서도 잘 고려하는게 중요하다. 책 예제에선 계좌를 생성하는 유일한 방법은 사용자가 계좌를 등록하는 방법뿐이므로 CreateAccount 보단 RegisterAccount 라는 네이밍이 더 명확하다.
- 위처럼 나누게 되면 서로 다른 연산에 대한 동시작업이 쉬워진다. 여러 개발자가 병렬적으로 작업해도 병합 충돌이 일어나지 않을것이다.
유지보수 가능한 소프트웨어를 만드는데 어떻게 도움이 될까?
- 애플리케이션 계층은 HTTP 에 대한 상세 정보를 노출시키지 않도록하면 웹 어댑터를 다른 어댑터로 쉽게 교체 가능하게 된다.
- 웹 컨트롤러는 단위가 더 작을수록 파악하기 수월해지고 테스트하기도 쉬워지며 동시작업을 효율적으로 만든다. 세분화된 컨트롤러는 초기엔 공수가 더 들지라도 유지보수 관점에선 훨씬 더 좋다.