Ch5 웹 어댑터 구현하기

[YeongHyeon-Kim]

p55) 실시간 데이터를 사용자의 브라우저로 보내는 경우 반드시 포트가 필요하다 -> 5.2의 그림에서는 서비스에서 나갈(아웃고잉) 할 방법이 없다. ex) 채팅 전송 -> 한명의 유저가 채팅을 보낼때 온 메세지는 adapter 에서 in으로 들어가서 서비스로 들어가게 되고 그 메세지에 대한 내용을 다른 유저들에게 보여줘야 하니까 out으로 나가서 웹 소켓 컨트롤러를 통해 보여지게 된다.

(지수) 서비스에서 꼭 adapter로 나갈필요는 없다. 서비스에서 out으로 보내고 그 out은 또 다른 서비스의 in이 될수도 있다.

[YeongHyeon-Kim]

p60) 계좌송금인데 PostMapping에서 PathVariable처럼 url로 지정해서 보내도 괜찮은지? 그냥 예시여서 이렇게 나타낸것인지?

• REST API와 보안 사이의 tradeoff 라고 생각하면 됨.
• 만약 요구사항에 꼭 보안을 지켜줘야 한다는게 있다면 HTTP면 RequestBody도 결국 보여지니까 HTTPS 적용해야 안전할듯 하다.
• header에 토큰을 추가하는 등 다른 보안 방법을 추가하는 것도 괜찮을 것.

[s-ryuri]

p57) 우리가 바깥 계층에서 HTTP를 다루고 있다는 것을 애플리케이션 코어가 알게 되면 HTTP를 사용하지 않는 또 다른 인커밍 어댑터의 요청에 대해 동일한 도메인 로직을 수행할 수 있는 선택지를 잃게 된다.

정리 :

• 알게 되면 -> 의존성을 가지게 되면이라는 의미
• 웹 어댑터를 통해서 애플리케이션 코어로 값만 넘겨주면 되는데
• 코어에서 이 비즈니스 로직을 가지게 되면 의존성을 가지는 것과 마찬가지기에
• http에서 다른 걸로 바꾸게 되면 모든 비즈니스 로직을 바꿔야되니 문제가 발생하게 된다.

[InHyeok-J]

웹 어댑터의 책임중 인증 및 권한 검사를 한다고 하는데 Spring Security를 사용하면 Filter 기반의 검사를 사용하고 몇 가지 케이스로 구현하는데 그 중

• (1) 인증 획득하기 / UsernamePasswordAuthenticationFilter 를 사용해서 form Login 기반의 인증 얻기(Session , JWT ..etc) 등
• (2) 얻은 인증 기반의 검사하기 ... 주로 JWT를 사용할때 Filter를 직접 만들어서 특정 요청이 들어올때마다 호출 (GenericFilterBean or abstractauthenticationprocessingfilter ...extends)

여기서 2번의 경우는 인증 검사만 처리하기 때문에 웹 어댑터의 영역이라고 생각이 드는데 1번 같은 경우는 유저가 있는지 검사하고(DB에 접근), Password가 맞는지 등 비지니스 규칙을 검증해야 할 수 있는데 그러면 웹 어댑터가 아닌 Application core로 가는거라고 생각이 드는데

이렇게 Security 관련 Filter들과 그 외 코드들이 여러 곳에 있으면 개발하는데도 혼동이 오고, Security Config 파일을 어디다 둬야하는지.. 만약 분산돼있으면 package 관련 access도 public하게 열어둬야할것 같다는 생각이 드는데요 위같은 경우는 어떻게 처리해야 될까요

정리

• Security도 자체의 어댑터로 볼 수 있다
• 비지니스 로직( DB 접근 , 중복검사) 등을 한다면, Filter (어댑터) -> use Case로 접근하면 될 듯.!