회고
초기 스케치 및 테이블 명세서 작성
요구사항을 바탕으로 각 도메인별로 컬럼을 나열하여 테이블 명세서 역할을 할 수 있는 기초 스케치를 시작했다. 처음에는 draw.io를 사용하려 했으나, 컬럼 설정과 도식화에 불편함을 느껴 Notion으로 옮겨 작업했다. 각자의 파트에 따라 나누어 작성한 후, 공통적으로 놓친 부분을 체크하며 정리해 나가면서 점점 윤곽이 잡혀가는 느낌을 받았다.
ERD 작성 및 도메인 간 연관관계 설정
튜터님의 조언으로, 전체적인 구조를 시각적으로 파악하기 위해 ERD 작성이 필요하다는 제안이 있었다. 이에 따라 erdcloud를 활용하여 명세서 내용을 기반으로 테이블과 컬럼을 추가하며 ERD를 설계했다. 도메인 간 연관관계를 고민하며 점차 서비스 구조와 흐름을 구체화할 수 있었고, 이를 통해 추가해야 할 부분을 빠르게 파악할 수 있었다.
협의 과정과 토론
ERD 작성 과정에서 플로우 문제, 성능 고려 사항, 논리적 타당성에 대해 활발한 토론이 이루어졌다. 의견이 갈리는 부분에서는 다수결로 결정하되, 필수 요구사항을 바탕으로 필요한 요소들만 제한적으로 추가했다. 서비스의 완성도를 높이기 위해 각자 익숙했던 사용자 경험에서 필요한 사항을 보완하는 과정도 의미 있었다.
API 명세서 작성
대부분 기본 CRUD 였기 때문에 완성된 ERD를 기반으로 API 명세서를 작성했다. 팀장님과 내가 사용하는 방식 각각의 장점을 조합하여 구조를 결정했으며, 내일 오전까지인 빠듯한 일정으로 인해 쿼리 스트링, 파라미터, 반환값 등 세부 사항은 이후 보완하기로 했다. 작업을 분담하여 작성 후 회의로 내용을 검토하고 보완해 나갔다. 해결이 어려운 부분은 튜터님의 조언을 받기로 했다.
인상 깊었던 것
-
Auditing 분리
ERD에서는 가독성을 높이기 위해 Auditing 컬럼을 별도의 테이블로 분리하였다. -
AI 자동 생성 메뉴
AI가 생성하는 메뉴 설명에 대해 기능을 확실히 정의하고, 테이블을 분리하는 과정을 도입했다. -
주문 지역의 제한
사용자와 가게의 배달 가능 위치를 각각 관리하기 위해 주소 코드로 유저와 가게의 위치를 테이블로 분리하는 방법을 사용했다. -
결제 API 활용 논의
결제 API 사용 시점과 주문 과정 내에서 결제 단계를 거치는 흐름에 대해 심도 있는 논의를 진행했다. -
API Path 설정
도메인 우선 구조와 계층 구조 사이에서 API Path를 설정하기 위한 논의가 이루어졌다.