상품에서 유저 수정 권한 관련 문의드립니다!!

안녕하세요. 요한님

말씀하신 내용을 들어보니, 아마도 사용자 접점의 서비스 API와 내부에서 사용하는 내부 API가 공존하는 것 같습니다.

저는 이 부분은 명확하게 다음과 같이 package부터 api path까지 고려해서 함께 API를 분리하는 것이 좋다고 생각합니다.

- 서비스 API: 실제 사용자 접점에서 사용하는 API, 외부에 열려있고 보안에 매우 취약한 API들로 구성, 대부분 사용자 인증이 필요하고, id + userName 파라미터가 함께 필요함

- 내부 API: 내부망에서 사용하는 API, 어드민, 배치, 시스템 통합, 연동 등등 내부에서 특정 사용자 인증과 관계없이 사용

서비스 API와 내부 API는 공통의 관심사가 다르기 때문에 시간이 지날수록 다르게 발전하는 경향이 있습니다. 서비스 API는 사용자 접점의 변경 라이프 사이클을 따르지면, 내부 API는 내부 시스템간의 변경에 따라 달라지기 때문입니다. 그리고 어드민에서 사용하는 데이터와 사용자에게 노출하는 데이터도 서로 많이 다릅니다. 결국 시간이 지날수록 서로 다르게 발전하게 되는 것이지요.

이렇게 컨트롤러는 이렇게 분리해두고 중복 제거를 위해 공통 로직은 필요하면 공통 클래스(공통 컴포넌트나 서비스 클래스, 또는 이미 만들어서 함께 사용할 수 있는 서비스 클래스)를 만들어서 사용하면 됩니다.

그리고 package와 api path를 분리해두면 특정 URL이나 패키지에 따른 다른 공통 관심사를 따로 적용할 수 있습니다.

감사합니다^^

네^^ 감사의 인사까지 저도 고맙습니다 :)

요한님 처럼 계속 의심하고 더 나은 방법이 없는지 고민해야 결국 좋은 개발자로 성장할 수 있다 생각해요.

아키텍쳐에 대한 강의는 언젠가 먼 미래에 꼭 준비할께요 ㅎㅎ

고맙습니다!

늦은 새벽시간에도 이렇게 답변주시니 감사합니다!!   내부 api와 서비스 api가 서로 다른 방향으로 발전해 나간다고 말씀해 주신 부분을 듣고 무릎을 탁 치게 되었습니다!! 속이 뻥 뚫리는 느낌입니다ㅎㅎ

조금 다른 소리일 수 있겠지만 좋은 패키지 분리와 아키텍쳐에 대해서도 더 공부해야 될 것 같은 생각이 또 드네요! 

다른 질문의 답변글에서 보았던 영한님의 여건이 되실때 아키텍쳐에 관한 강의도 개설하실 수 있다고 하셨는데 querDsl 열심히 공부하면서 기다리고 있겠습니다..!ㅎㅎ 꼭 개설해주셨으면 하는 바람입니다!

감사합니다~!

안녕하세요. 요한님^^

궁금한 점이 있는데요. 이 로직이 항상 리팩토링 해달라고 신호를 보낸다고 하시는데, 어떤 이유 때문인지요?

현재 로직을 조금 더 자세하게 로직을 적어주시고, 어떤 점이 부담스러운지 코드로 말씀해주시면 더 도움을 드릴 수 있을 듯 합니다^^