[회고록] TripMate 기획

이번 프로젝트는 여행의 일정을 등록하여 동행자를 구할 수 있는 여행메이트 서비스다.

예를들면, 일본에 혼자 여행을 떠난다고 했을 때 혼자서는 여러 음식을 먹기 힘들어 친구와 여행을 왔다면 여러 음식을 시켜서 먹었을텐데.. 라는 생각을 해본 경험. 또는 레일바이크같은 체험을 할때 혼자가 아닌 2인으로만 티켓을 구매해야한다면 동행을 구해야만 한다. 혼자 여행을 해본 적이 있다면 한 번씩은 혼자 여행을 떠날 때 아쉬운 경험을 했을 것 같다고 생각해 이러한 경험을 바탕으로 이러한 서비스를 만들고자 한다.

 

프로젝트의 주요 기능으로는 일정을 등록하여 동행자를 모집하는 기능, 실시간 매칭 서비스, 일정에 등록되어있는 상품, 상품 구매와 결제 등으로 이루어져 있다. 

초기 erd

이제 기획단계를 끝맺힌 상태인 erd이고 구현을 하면서 수정이 계속 일어나지 않을까 싶다.

 

노란색부분인 일정 도메인(Plan)을 맡게되었다.

 

복잡한 프로세스를 draw.io를 이용하여 아래와 같이 간단히 어떤 서비스의 데이터가 받아오는지 정리했다.

일정 도메인은 일정을 등록할 때에는 상품 서비스에서 데이터를 받아온다. 조회할 때에는 일정 확정 전, 일정 확정 후, 마이페이지로 나뉘며 일정이 확정되기 전에는 취소할 수 없는 정책으로, 확정되기 전에는 모집을 계속 해야하기 때문에 최신화된 상품 데이터를 받아와야하고 확정이 되었다면 모집이 끝났기때문에 최신화된 데이터를 불러올 필요가 없고 모집이 확정되었을 때의 상품 데이터를 스냅샷으로 저장되는 방식으로 구현했다.

 

이번 프로젝트를 하면서 새로 알게된 점을 작성해보자면

테이블 명세서를 작성할 때 필드가 NOT NULL /  NULL인지에 대한 고민을 크게 하지 않았던 것 같다. 단순히 해당 필드가 존재해도 되고 존재하지 않아도 된다면 NULL로 적용했던 것 같다. 하지만 이번에 진행하면서 이러한 방식으로 NULL을 사용하게 된다면 NULL로 db에 저장이 된다면 진짜 없는건지, 누락되었는지 알 수가 없다. 코드가 변경이 되면서 데이터가 저장될 때 잘못 들어가게 된다면 어떠한 방식으로 데이터를 저장했는지 알 수가 없다. 그렇기 때문에 잘 못 들어갈 여지를 좁힐 수 있다고 판단했다.

이를 통해 NULL은 단순히 비워두는 선택지가 아니라, 비즈니스적으로 정말 필요한 경우에만 허용해야 한다는 점을 알게 되었고, 최대한 NOT NULL 중심으로 정책을 명확히 재설계했다.