최종 프로젝트를 진행하면서 멀티 모듈 설계에서 겪었던 이슈들을 몇 가지 공유하고자 한다. 먼저, 초기에 계획 된 우리 팀의 멀티모듈 구조는 다음과 같이 설계되었다. 위 사진처럼 멀티모듈 구조를 레이어별로 가져가기로 했다. 레이어별로 구조를 가져가기 이전에 먼저 모듈을 어떻게 가져가는 것이 좋을지에 대해 팀원들과 얘기를 나누었다. 하지만, 프로젝트 기간이 짧은 만큼 도메인이 많이 발생 할 것으로 예상되지 않고 멀티 모듈을 구성했을 때 모듈 별로 부트 서버를 따로 띄울 일이 프로젝트 구조 상 발생하지 않을 것 같다는 전제에서 시작했다. 고민을 레이어별로 모듈을 나누는 것과 도메인 별로 모듈을 나누는 것 두 가지를 고려했기 때문에 자연스럽게 레이어 별로 모듈을 가져가기로 결정하였다. 참고로, 멀티모듈을 어떻게..
프로그래머스 데브코스에 참여한지 이제 거의 6개월이 다 되어간다. 현재는 최종 프로젝트 기간 중 QA 기간이라 포스팅을 쓸 시간이 생긴 것 같아 하루에 겪었던 이슈들을 하나씩 정리해보려고 한다. 그 중에서는 일정 관리 부분이 가장 중요했던 것 같다고 생각하여 이를 얘기해보고자 한다. 서론 프로젝트를 진행하기 전에 프로그래머스에서 '일하는 우리'의 지윤정님의 강의를 통해 협업에 임하기 전에 배워야 할 태도와 애자일 방식의 프로젝트 관리를 방법을 간단하게 배우게 되었다. 저번 1차 클론 코딩 프로젝트에서는 제대로 진행이 되지 않았지만, 최종 프로젝트에서는 애자일한 협업을 한 번 해보고자 마음을 먹었다. 팀원분들이 대부분 내향적인 성격을 가지신 MBTI I로 구성이 되어있었다. 스크럼을 이끌어가는 것은 그래도..
서두 동작을 설명하기 이전에 지역 데이터를 스프링의 캐시 기반으로 조회를 하려고 했던 배경에 대해서 먼저 소개하겠습니다. 현재 진행 중인 프로젝트에서는 사용자들이 자신의 선호지역 혹은 자신이 검색하고자 하는 지역들을 선택 할 수 있습니다. 이를 클라이언트에서 불러오기 위한 방법을 2가지를 떠올렸습니다. 1. 먼저 시를 선택하면 시에 해당하는 id 값을 서버에 보내서 구를 가지고 오는 api를 호출한다. 2. 구가 도착하면 다시 구를 선택하고 구에 해당하는 id 값을 서버에서 보내서 동을 가지고 오는 api를 호출한다. 3. 마지막으로 동을 선택한다. 위와 같은 과정은 먼저 3번의 네트워크를 타야하고, 유저가 어떤 시, 구, 동을 선택할지 예상 할 수 없었습니다. 캐시를 사용한다고 하더라도 각 시에 호출,..
멀티 모듈을 적용한 계기 우리 팀이 진행한 캐치 테이블을 클론 코딩한 Dev-table 에서는 다음과 같은 기능을 구현하고자 하였다. 유저의 예약, 웨이팅 점주의 예약, 웨이팅 예약, 웨이팅을 알려줄 수 있는 알림 처음에는 이러한 기능들을 모두 하나의 모듈에서 처리하도록 구성을 해두었다. 즉, 다음과 같은 패키지 구조가 나타나게 된다. devtable ㄴ src ㄴ main ㄴ domain ㄴ reservation ㄴ application ㄴ OwnerReservationService ㄴ UserReservationService ㄴ presentation ㄴ OwnerReservationController ㄴ UserReservationController ㄴ waiting ㄴ application ㄴ O..
서론 이번 주차에는 특별한 일들이 많았다. 하나씩 차근차근 있었던 일들을 정리해 볼 필요가 있었다. 프로젝트의 설계 먼저, 캐치테이블을 클론 코딩을 하기 위한 애플리케이션의 분석 및 erd 설계, 유저 스토리 정리가 마감이 되고 월요일 날 멘토님에게 컨펌을 받을 필요가 있었다. 캐치 테이블을 클론 코딩을 하기 위해 도메인을 분석하면서 나타나게 된 도메인은 7개 정도로 추려졌다. 하지만, 3주 동안의 클론 코딩을 진행하면서 7개의 모든 핵심 도메인을 구현한다는 것은 욕심이라고 생각이 들었고, 팀원들에게 다음과 같은 의견을 제시했다. "캐치 테이블이라는 애플리케이션은 본래 어떤 것을 목적으로 만들어졌을까요? 제가 생각하기에는 손님과 점주간의 관계에 있어서 예약과 웨이팅이라는 서비스를 편리하게 제공하고자 하는..
이번 주 또한 쉬어가는 주여서 부족했던 부분을 보충 할 수 있는 주였다. 특히, 앞으로의 프로젝트 과정에서 모니터링이 중요하다고 생각하여 그라파나, 프로메테우스와 같은 모니터링에 대해서 공부를 했었다. 월요일날에는 타다 본부장님인 지두현님의 세션이 있었다. 세션에 대한 내용은 타다의 스프린트 방식에 대해서 알아볼 수 있는 내용이었는데, 말로만 들어오던 애자일 방식의 업무 진행이 어떻게 이루어지는지에 대해서 지두현 본부장님께서 잘 설명을 해주셔서 이해가 정말 잘 되었다. 그리고 지두현님께서 모든 세션에 대한 강의를 마치고 질문을 5개 정도 받는다고 말씀을 해주셨다. 나는 최근에 본 구현을 해야 할 용기에 대한 내용을 바탕으로 조금 예민할 수 있는 질문을 드렸다. 어떠한 유저들에게 굉장히 도움이 되는 아이디..
이번 주는 쉬어가는 주차였다. 프로젝트를 어떻게 설계하는 것이 좋고 컨벤션은 어떻게 가져가는 것이 좋은지, 프로젝트를 진행하면서 어떤 툴 들을 주로 사용하고 실무에서는 어떤 형태로 진행을 하고 있는지에 대한 내용 폭포수 방식의 개발과 애자일 방식의 개발의 차이, 그리고 PO, 스크럼 마스터의 역할과 스크럼을 어떻게 진행하는 것이 좋은지 이러한 두 가지 방식에 대한 학습이 이루어졌다. 이전까지보다 편하게 들을 수 있었고 프로젝트 진행 간 어떻게 진행을 해야되는지 고민을 하다가 미루고 미뤄두었던 깊게는 알지 않더라도 UI 부분을 처리하기 위한 리액트 프레임워크에 대한 학습을 지금 해야 될 것 같다는 생각을 하였다. 프레임워크로써 정해진 것만 수행하면 편하게 할 수 있는 Vue와 React 중에 결국 Reac..
어느새 프로그래머스 10주차가 되었다. 이번 주차에서는 Spring Security를 배웠다. Spring Security의 기본 아키텍쳐를 시작으로 자주 쓰이는 Filter들에 대해서 강의가 진행되었다. 강의 내용이 Security 5로 진행이 되었지만 Spring Boot 3.1.2 버전에서는 어떻게 적용되는지 궁금해서 강의 내용은 Security5로 구조에 대해서 공부를 하고 실습을 진행하면서 Spring Security 6로 리팩토링을 진행하였다. Spring Security 5에서 6로 변경되면서 Deprecated 된 부분이 많아서, 리팩토링하는데 조금 고생했지만 리팩토링을 하면서 디버깅 하는 방법에 대해서도 익숙해질 수 있었고, 그리고 공식문서를 읽는 것도 조금 익숙해졌다. 블로그 글을 보는..
