Product·Variation·Cartitem·Order·Payment·OrderProduct를 구분하고 ORM 관계로 연결합니다. 프로젝트 DBMS는 MariaDB이며 상품·옵션·장바구니·주문·결제의 관계형 모델을 설계했습니다. 공개 저장소의 개발 설정 및 캡처용 로컬 환경과 프로젝트 사용 DBMS를 구분합니다.
View와 응답
URL에서 View를 호출하고 ORM 조회 결과를 Template에 전달합니다. 결제 화면은 PayPal JavaScript SDK를 사용하며 onApprove에서 capture한 결과를 Django payments에 전달하고 JSON 응답으로 주문 완료 흐름을 연결합니다.
핵심 처리 흐름
상품 선택부터 주문 완료까지
현재 구현의 흐름입니다. 주황색 영역의 결제 결과 수신은 결제사 서버 검증 완료를 뜻하지 않으며, 원자적 트랜잭션으로 묶인 상태도 아닙니다.
상품과 옵션 선택 후 비회원은 세션 Cart, 회원은 Account 기준으로 장바구니를 조회합니다. 같은 상품·옵션이면 수량을 증가시키고 다르면 새 항목을 생성합니다. 로그인 후 주문 폼을 검증해 미완료 주문을 만들고, PayPal SDK 승인·캡처 후 브라우저가 보낸 결과로 Payment와 OrderProduct를 저장하고 재고를 감소시킨 뒤 장바구니를 지웁니다. 서버 측 결제사 검증과 트랜잭션은 후속 개선 과제입니다.
01. 상품보다 세밀한 장바구니 식별
Product가 같아도 Variation 조합이 다르면 별도 항목입니다. add_cart는 기존 항목의 variation 목록과 요청 옵션을 비교해 같으면 quantity를 1 증가시키고, 다르면 새 Cartitem을 생성합니다.
02. 세션과 계정을 소유자로 사용
비회원은 세션 키로 Cart를 찾고 회원은 user로 Cartitem을 조회합니다. 로그인할 때 두 장바구니의 옵션을 비교하여 회원에게 연결하는 분기가 있습니다. 병합 시 수량 처리의 정확성은 추가 개선이 필요한 부분입니다.
03. 주문 생성과 주문 확정을 분리
place_order는 장바구니에서 총액을 계산하고 OrderForm이 유효하면 주문을 저장합니다. 날짜와 DB ID를 조합해 order_number를 만들고, 아직 is_ordered가 false인 주문을 결제 화면에 전달합니다.
04. PayPal 결과와 구매 시점 데이터 저장
PayPal onApprove에서 actions.order.capture를 호출하고 결과를 payments로 전달합니다. 서버는 요청 사용자의 미완료 주문을 찾고 PayPal 결제 방법과 응답 상태를 Payment에 저장합니다. 각 장바구니 항목의 수량·상품 가격·옵션을 OrderProduct로 옮긴 뒤 재고를 차감하고 장바구니를 삭제하며, 마지막에 이메일과 JSON 응답을 처리합니다.
03 / RESULTS & VALIDATION
결과/검증 — 그래서 무엇이 좋아졌는가
실제 서비스 적용 여부
소스 코드가 공개된 쇼핑몰 학습 프로젝트입니다. 실제 서비스 적용 여부는 작성자 확인이 필요합니다.
구현된 구매 흐름
저장소 수준에서 상품 탐색, 옵션별 장바구니, 주문 생성, 구매 시점 가격·수량 기록을 확인했습니다. 매출이나 사용자·회사 효과를 입증하는 운영 자료는 아직 없습니다.
검증 방법과 근거
공개 저장소의 PayPal SDK와 payments 코드를 확인했습니다. 별도 SQLite 시연 DB에서 상품 목록·상세·장바구니 화면을 실행해 캡처하고 비회원 상품 추가를 확인했습니다. PayPal 거래를 실행하지 않았으며 서버 측 결제 검증과 원자적 주문 처리 등은 추가 확인이 필요합니다.
