코드를 정리하고 재확인하면서 생긴 문제가 있었다. { "email": "이메일@naver.com" } 인데 email을 오타로 eamil이라든지 아무튼 잘못 작성하면 null 값으로 들어오는데 해당 부분 같은 경우는 프론트엔드랑 의사소통용으로 에러를 지정해서 던져주는 게 좋은 것 같다. 이후 협업할 때 꼭 미리 설정해둬야하는 내용인 것 같다.

TC를 공부하고 작성하고 있는데 현재 작성했던 내용들이 TC에 너무 부적합하고 이미 많이 진행된 상태에서 확인하다보니 아쉬운 점이 하나하나 보이기 시작했다. 기능 단위를 작게 분리하지 못하고 구현하는데 정확히 어디서 에러가 발생할지 예측 못했던 이유도 더 명확히 알 수 있었다. 기능 단위별로 정확한 리턴 값을 확인하며, 확인하지 않았고 현재 완성된 코드에서도 Service와 Controller의 return값이 이어지지 않았다. 어제 TIL에 작성한 내용처럼 Global rule을 정하지 않았던 문제와 디자이너 문제가 맞물려서 해당 내용을 수정할 수도 없다. 아쉽지만 현재 어떤 문제를 가졌고 TC를 통해 해결할 수 있다고 알게돼서 현재 단계에서 TC를 작성해 TC와 조금 더 친해지는 것으로 만족해야겠다.

Error message, Http Status, Response Data와 관련된 내용들을 정리하다가 무언가 잘못되고 있는 것을 인지했다. 뒤늦게 해당 부분을 모두 통일해서 고쳐나가려고 했는데 오류가 발생했다. 현재 프론트는 디자이너 없이 작업을 진행 중이여서 시간에 많이 쫓기고 있는 와중에 코드도 많이 작성된 상태이고, 해당 부분을 통일해서 수정하기 어려운 상황이다. API명세서를 작성하며, 해당 내용들을 어떻게 받아야하는지 계획이 됐어야 했는데, 해당 부분을 협의해가며 진행할 수 있다고 크나큰 착각을 했다. 아직 시간이 남았으니 추후에 어떻게 진행할 수 있을지 더 좋은 방법을 찾아야겠다.

오늘은 security와 filter를 이용해서 exception handling을 마무리 지었다. 처음에 작성할 때는 너무 어려워서 뭐가 무슨 내용인지 정확하게 이해하지 못했었는데 이제는 어떤 역할이고, 어떤 로직을 타고 흘러가는지 흐름도 이해했다. 너무 간단한 내용이였는데 초반에 세팅할 때 왜 이렇게 이해가 어렵고 잘 못해 시간을 끌었는지 팀원들에게 미안하다. 그리고 어제 헷갈렸던 캐시에 대해서 더 찾아봤는데 캐시에 대해서 제대로 이해한 것이 맞았는데 우리 프로젝트에서는 최초에 userDetails를 db에서 한 번 끌어다가 사용하고 이후 redis에 저장한 데이터를 사용하는 로직을 이해하지 못해서 헷갈렸었다. 해당 로직이 만들어지는 과정에 팀원의 로직을 보고 기존에 redis에 데이터를 저장하는 로..

DDD(Domain Driven Design) Domain(유사한 업무의 집합)으로 묶어서 설계를 하는 방식인데 Domain을 얼마나 소분화해서 구분하느냐가 주관적이게 느껴졌는데 해당 부분이 더 확장 가능성이 없으면 Domain으로 묶지 않는 것을 기준으로 했다. 그리고 cache를 공부하면서 헷갈리는 부분이 생겼는데, redis를 활용해서 데이터를 저장하는 것이 캐시와 같은 역할이라고 생각이 드는데, 정확히 어떤 차이점을 가지고 있으며, 어떠한 기능적 차이가 있는지를 명확하게 알지 못했다. 내일은 이 부분에 대해 더 깊게 공부해봐야겠다.

토큰 만료 전략을 정확하게 공유하지 않은 상황에서 토큰 만료 2분 전에 새롭게 토큰을 발급하는 로직을 작성했다. 해당 내용에서는 프론트엔드의 기존에 reponse Header의 Authorization에 있는 token 정보를 저장하고 이후 행동에서 해당 token을 다시 보내주는 로직이 있으면 충분하다고 생각해서 프론트에서 특별한 행동을 하지 않아도 완성할 수 있다고 생각했다. 이에 따라서 기존에 있던 토큰 유효성을 검사하는 API가 필요하지 않다고 생각했고, 프론트엔드와 의사소통 하지 않고 해당 내용을 삭제했다. 그런데 해당 내용은 백엔드에서 권한을 제한하던 것과 같은 역할을 하는 API였고, 해당 내용을 정확하게 인지하지 못해서 이 부분을 필요하지 않다고 판단해서 오류가 생겼다. 그래서 각 API ..