팀원들과 모여서 무작정 ERD 작성부터 하려고 하니 튜터님께서 방문하셔서 순서에 대해 알려주셨다.
예를 들어 게시글 도메인을 통해 테이블 명세서를 작성하고 API 명세서까지 작성하는 순서에 대해 설명해주셨다.
[ ] 반복적으로 등장하는 키워드 = 우리가 관심을 가지는 영역 = 관리가 필요한 영역 = 도메인
[ ] 게시글 = 도메인
[ ] 게시글 도메인 관리에 필요한 데이터 고민
[ ] 게시글 식별을 위한 식별자
[ ] 게시글 제목 표현을 위한 필드
[ ] 게시글 내용 표현을 위한 필드
[ ] 게시글 작성자 표현을 위한 필드
[ ] 게시글 작성/수정/삭제 주체와 일자
[ ] 도메인 관리에 필요한 데이터 고민 완료 → 테이블 명세서 옮김
[ ] 옮기는 과정에서 고민해야할 건 데이터 타입, 제약조건
[ ] 데이터 타입, UK 와 같은 데이터베이스 테이블 관리 및 테이블의 각 컬럼을 관리하기 위해 필요한 제약조건 고민
[ ] 게시글 도메인과 연계된 도메인간의 연관관계를 파악
[ ] 게시글 작성 시 포인트 지급
[ ] 게시글 삭제 시 포인트 회수 및 해당 게시글에 작성된 댓글 삭제
[ ] 연관관계를 파악 해볼 수 있음
[ ] 예를 들면
[ ] 게시글(1) ↔ 댓글(N)
[ ] 게시글(1) ↔ 포인트(1)
[ ] 연관관계에 따른 도메인 후보 선출 : 게시글, 포인트, 댓글
[ ] 데이터 생애주기에 따라 같은 도메인인지를 고민
[ ] 예를 들면,
[ ] 게시글 삭제 : 해당 게시글의 댓글을 전부 삭제 = 삭제 생애주기가 동일
[ ] 게시글 조회 : 게시글을 조회 시 해당 게시글에 등록된 댓글을 함께 조회 = 조회 생애주기가 동일
[ ] 게시글 생성/수정 : 생성과 수정 요청이 댓글과는 다르게 동작
[ ] 게시글 도메인 관리를 위해 필요한 데이터를 저장하고 관리하기 위한 테이블 명세서
[ ] 식별자 타입은 무엇으로 할것인지
[ ] 각 필드를 잘 관리하기 위해 필요한 데이터 타입 고민
[ ] 제약조건 = 게시글 제목의 중복을 허용o or 허용x → UK
[ ] 연관된 테이블과의 관계를 도식
[ ] 게시글 ↔ 댓글 = 1:N 관계이므로, 댓글 테이블에 게시글 번호를 FK 추가
[ ] 작성된 테이블 명세서를 도식화로 옮기면 → ERD
[ ] 도메인/데이터에 대한 설계 이후 기능단위로 제공하기 위한 API 명세서 작성
[ ] 해당 기능 혹은 데이터를 생성/수정/삭제/조회 하기 위해 필요한 요청값은 무엇이 있는지, 어떤 Http Method로 요청해야하는지, 요청 주소(Endpoint)는 어떻게 구성할지, 응답은 어떤 데이터를 내려줄지, 응답코드(Http Status Code)는 어떻게 정의할지
[ ] RESTful 원칙에 따라 API 설계
[ ] URL = 자원의 위치는 복수형의 명사로 표현, 계층형
[ ] PUT /board/1/comments/1
[ ] board
[ ] 1번 게시글
[ ] 댓글
[ ] 1번 댓글
[ ] Http Method = 행위는 동사로 표현
[ ] GET/PUT/POST/PATCH/DELETE
우리는 전날 기능 분석을 한 페이지를 보며 도메인을 추출했다.
일단 1. 사용자 2. 허브 3. 업체 4. 주문 5. 배송 이렇게 다섯가지로 나누었고 발제문을 보며 필요한 엔티티에 대해서도 추가로 작성하였다.
1. 사용자 + 슬랙메세지
2. 허브, 허브간 이동경로
3. 업체, 상품
4. 주문, 주문 목록
5. 배송, 배송 경로, 배송담당자
다섯가지로 나누어 하나씩 맡아 도메인을 분석하고 테이블명세서와 ERD를 작성하기로 했다.
모두 끝나면 취합을 해서 수정할 부분을 수정하고 API 명세서로 넘어가기로 했다!
나는 배송 도메인을 맡았고 튜터님이 하시는 방식으로 나도 분석을 했다.
담당 도메인 : 배송
[ ] 배송 도메인에 필요한 데이터
배송 식별자
어떤 주문에 대한 배송인지를 위한 필드
출발 허브
도착 허브
배송지 주소
현재 상태
현재 상태 Enum HUB_WAITING HUB_MOVING HUB_ARRIVED OUT_FOR_DELIVERY DELIVERED
수령인
수령인 슬랙 id
업체 배송 담당자 id
created_at / created_by
updated_at / updated_by
deleted_at / deleted_by
[ ] 배송 도메인 → 배송경로 도메인
배송(1) 이 생성되면 배송 경로가 생성
배송 경로는 주문 생성 시점에 모든 경로를 미리 생성 ( 변하지 않음 )
배송 조회 시 배송 + 배송 경로 함께 조회
배송 방법이 P2P인 경우 배송(1) ↔ 배송 경로 (1)
배송 방법이 Hub and Spoke / P2P + Hub and Hub Relay / Hub to Hub Relay 인 경우 배송(1) ↔ 배송 경로 (N)
☆ 배송 방법 정해야함 !
[ ] 배송 경로 도메인에 필요한 데이터
배송 ID
시퀀스(배송 경로 상 허브의 순번)
출발 허브 ID
도착 허브 ID
예상거리
예상 소요시간
실제 거리
실제 소요 시간 → nullable 가능 (배송 완료 후 채움)
현재상태
현재상태 Enum ( 상의 및 수정 필요 ) 허브 이동 대기중, 허브 이동중, 목적지 허브 도착, 배송중
배송 담당자 ID
created_at / created_by
updated_at / updated_by
deleted_at / deleted_by
[ ] 배송 담당자 도메인에 필요한 데이터
배송 담당자 id ( 사용자 id와 동일 )
소속 허브 id → nullable 가능 ( 허브 배송 담당자인 경우 Null? )
slack id
배송 담당자 type (허브 배송담당자인지 업체 배송담당자 인지)
배송 순번 → 라운드 로빈 방식 배
created_at / created_by
updated_at / updated_by
deleted_at / deleted_by
이렇게 각 엔터티에 필요한 데이터를 정리하고 테이블 명세서를 작성하면서 튜터님께 질문할 사항과 팀원들과 상의하여 정해야할 부분에 대해서도 정리했다.
테이블 명세서
- p_delivery 배송 테이블
p_delivery_path 배송 경로 테이블
p_delivery_manager 배송 담당자 테이블
튜터님께 질문 사항 및 해결 방법 Q. 배송담당자의 PK를 user 테이블에서 사용하는 ID로 해도 되는지
A. 회원에서 마스터, 허브 관리자, 배송담당자, 업체 별로 나누는건데 각자가 필요한 정보가 다르기때문에 배송담당자라는 테이블을 분리한 것
→ 배송 담당자에서 회원 테이블의 user_id 를 PK로 사용하게 되면 배송담당자 테이블에서 어떠한 역할을 가지고 있는지 식별 불가능 → p_user의 user_id를 FK로 가져오고, 배송 담당자 테이블의 고유 PK를 만들어야함.
Q. 동일하게 주문테이블이 하나 생기면 배송 테이블도 하나가 생기는데 주문 id도 동일하게 배송 테이블의 pk로 지정해도 되는지
