[과제] Spring 플러스 프로젝트 Day 1

1. 오늘의 프로젝트 개요

주제: 성인 인증 기반 프리미엄 주류 이커머스 서비스 구축.

목표: 복잡한 커머스 로직을 견고한 데이터 모델로 구조화하고, 팀 내 기술적 의사결정 프로세스 수립.

2. 오늘의 핵심 쟁점: 배송(Delivery) 데이터의 '부모'는 누구인가?

프로젝트 초반 ERD 설계 중 팀원과 가장 뜨겁게 논의했던 부분은 배송 정보를 결제(Payment) 테이블에 종속시킬 것인가, 주문(Order) 테이블의 하위로 둘 것인가였습니다.

팀원의 주장: 결제(Payment) 종속안

• 근거: 결제가 성공해야 배송 프로세스가 시작되므로, 결제 정보의 일부로 배송지를 관리하는 것이 직관적이고 조회가 간편하다.
• 우려되는 점: 비즈니스 로직이 '결제'라는 행위에 과도하게 묶여 유연성이 떨어짐.

나의 제안: 주문(Order) 하위 독립 도메인안

저는 다음과 같은 3가지 기술적/비즈니스적 근거를 들어 팀원을 설득했습니다.

① 데이터의 생명 주기와 불변성

• 결제 데이터는 승인 시점의 금액, 수단, 승인번호를 보존해야 하는 '정적'인 성격이 강합니다.
• 반면 배송 데이터는 운송장 번호 생성, 배송 상태 변경 등 끊임없이 변하는 '동적'인 성격입니다.
• 이를 하나로 묶으면 배송 상태를 업데이트하다가 실수로 결제 정보를 수정하게 되는 사이드 이펙트가 발생할 수 있습니다.

② 1:N 관계 확장을 통한 비즈니스 유연성

• 면접관이 "한 번 결제했는데 상품별로 배송지가 다르거나(선물하기), 재고 사정으로 일부 상품만 먼저 배송(부분 배송)해야 한다면?"이라고 질문했을 때, 결제에 귀속된 구조는 대응이 불가능합니다.
• 배송을 별도 엔티티로 분리하면 '1 주문 - 1 결제 - N 배송' 구조가 가능해져 미래의 요구사항에 유연하게 대응할 수 있습니다.

③ 도메인 기반 설계(DDD) 관점의 관심사 분리

• '돈을 지불하는 행위'와 '물건을 이동시키는 행위'는 엄연히 다른 책임을 가집니다. 각 도메인이 자기 역할에만 집중할 수 있도록 물리적으로 분리하는 것이 클린 코드와 유지보수의 핵심입니다.

3. 팀 커뮤니케이션과 해결

• 설득의 기술: "네 방식은 틀렸다"가 아니라, "우리 서비스가 나중에 '다중 배송지' 기능을 넣게 된다면 그때 DB 구조를 다 뜯어고쳐야 하는데, 그 리스크를 지금 줄여보는 건 어떨까?"라며 '우리'의 관점에서 협의가 완료되었습니다.
• 결과: 팀원도 확장성 측면에 공감하여 order_id를 참조하는 별도의 delivery 테이블을 설계하는 방향으로 합의했습니다.

4. 오늘의 성과물

• ERD 완성: Order를 브릿지로 하여 Payment와 Delivery가 독립적으로 연결된 구조 확립.
• 리뷰 시스템 설계: 상품 상세 조회 시 평점 기반 정렬 및 필터링이 가능하도록 review 테이블에 product_id(FK) 및 rating 컬럼 최적화.

5. 회고

"설계는 정답을 찾는 과정이 아니라 최선의 트레이드오프를 선택하는 과정입니다. 오늘 논의를 통해 데이터 무결성과 시스템 확장성이라는 두 마리 토끼를 잡을 수 있는 기초를 다졌습니다. 팀원과의 의견 차이를 논리적인 근거로 해소하며 협업의 즐거움을 느낀 하루였습니다."

 

 

 

피그마 다이어그램

 

ERD