이제부터는 이커머스 서비스의 본체에 들어갑니다. 06장까지에서 우리는 상품을 탐색하고, 사용자를 식별하고, 운영자 surface를 분리하는 바닥까지 만들었습니다. 하지만 아직은 사용자가 실제로 "구매를 시작하는 순간"이 없습니다. 그 시작점이 바로 Cart입니다.
장바구니는 단순히 상품을 임시로 모아 두는 화면이 아닙니다. 이후 주문 생성과 결제 확인의 입력이 되는 핵심 도메인 객체입니다. 따라서 이번 장에서는 화면보다 먼저, 장바구니가 어떤 규칙으로 움직이고 금액이 어떻게 계산되며 어떤 API로 노출되는지를 먼저 정리해야 합니다.
이번 페이지의 목적은 Cart를 "배열 하나"처럼 대충 다루지 않고, 사용자별 상태와 수량 규칙과 금액 계산 규칙을 갖는 도메인으로 세우는 것입니다.
주문은 장바구니의 결과입니다. 따라서 장바구니가 불안정하면 주문도 불안정해집니다. 예를 들어 아래 문제가 있으면 주문 단계에서 바로 터집니다.
그래서 이번 교재에서는 주문 생성을 바로 구현하지 않고, 먼저 Cart 도메인과 금액 계산 규칙을 고정합니다. 그래야 다음 페이지의 checkout UI와 그다음 장의 주문 생성이 안정적으로 이어집니다.
이 페이지를 읽고 나면 아래 항목이 정리되어 있어야 합니다.
Cart 도메인의 핵심 책임은 무엇인가이번 단계의 Cart는 아래 책임을 먼저 가져야 합니다.
중요한 점은 장바구니가 단순 UI 상태가 아니라는 것입니다. 장바구니는 결국 주문 생성의 입력이며, 따라서 서버 쪽에서도 규칙이 있어야 합니다.
장바구니는 누가 담았는지가 가장 중요합니다. 이 구분이 없으면 이후 모든 흐름이 무너집니다.
따라서 이번 교재에서는 장바구니를 반드시 사용자와 연결된 상태로 생각해야 합니다. 이 단계에서는 비회원 장바구니까지 확장하지 않더라도, 최소한 인증된 사용자별 cart는 분리되어 있어야 합니다.
이번 장에서 Cart는 최소한 아래 구조를 생각할 수 있습니다.
이 구조가 있어야 이후 주문 생성 시 "무엇을 몇 개 담았는가"를 명확히 설명할 수 있습니다.
장바구니 구현에서 가장 쉽게 무시되는 것이 수량 규칙입니다. 하지만 이 규칙이 없으면 금액 계산과 주문 생성이 다 흔들립니다.
이번 단계에서는 최소한 아래 기준을 먼저 정하는 것이 좋습니다.
이 규칙을 먼저 고정해야 프론트와 백엔드가 같은 동작을 기대할 수 있습니다.
이커머스에서 자주 나오는 선택은 아래 둘입니다.
이번 교재에서는 두 번째 방식이 더 자연스럽습니다. 그래야 사용자 경험도 단순하고, 이후 금액 계산도 명확해집니다. 중요한 것은 어떤 방식을 택하든, 화면과 서버가 같은 규칙을 써야 한다는 점입니다.
총액 계산을 화면에서만 해버리면 곧 문제가 생깁니다.
따라서 이번 단계에서는 최소한 기본 금액 계산은 서버 도메인 규칙으로 두는 것이 맞습니다. 프론트는 그 결과를 보여줄 수는 있어도, 최종 기준은 서버가 가져야 합니다.
아직 할인, 쿠폰, 배송비까지 다 넣을 필요는 없습니다. 이번 장의 첫 기준은 아래 정도면 충분합니다.
중요한 것은 계산이 단순하더라도, 그 계산 위치와 책임이 명확해야 한다는 점입니다. 이후 할인과 배송비를 붙일 때도 이 구조를 확장할 수 있어야 합니다.
장바구니 금액 계산은 결국 상품 가격을 기준으로 합니다. 이때 아래를 먼저 생각해야 합니다.
초기 교재 단계에서는 현재 상품 가격 기준으로 계산해도 충분하지만, 어떤 기준을 쓰는지 명확히 적어 두는 편이 좋습니다. 그래야 주문 생성 단계에서 금액 검증 방식도 설명하기 쉽습니다.
이번 단계에서 아래 정도 API면 충분합니다.
GET /cartPOST /cart/itemsPATCH /cart/items/{item_id} 또는 수량 변경 endpointDELETE /cart/items/{item_id}이 네 가지가 있으면 다음 페이지의 장바구니 UI와 checkout 진입 바닥을 만들 수 있습니다.
이번 교재에서는 장바구니를 사용자별로 관리하므로, cart API는 기본적으로 인증이 필요합니다. 이 규칙이 있어야 아래가 명확해집니다.
즉 cart는 첫 본격적인 인증 필요 API 집합입니다.
프론트가 장바구니 화면을 제대로 그리려면 아래 정도 정보가 있어야 합니다.
이 정보가 있어야 다음 페이지에서 checkout 요약도 같은 계약 위에 얹을 수 있습니다.
이번 단계에서도 오류는 단순 문자열로 넘기면 안 됩니다. 최소한 아래 경우를 먼저 생각해야 합니다.
이 오류는 다음 페이지의 UI 메시지와 재시도 흐름에 그대로 연결됩니다.
이번 장에서 완료라고 볼 수 있는 상태는 아래 정도입니다.
즉 아직 결제가 없어도, 구매 준비 상태는 성립해야 합니다.
이번 페이지를 코드와 실행 결과로 옮기면 최소한 아래 산출물이 있어야 합니다.
Cart 도메인 모델 또는 규칙이 산출물이 있어야 다음 페이지에서 storefront 장바구니와 checkout UI를 실제로 붙일 수 있습니다.
이 여섯 가지 실수는 다음 장의 checkout과 주문 생성에서 바로 구조 비용으로 돌아옵니다.
이 페이지에서 우리는 Cart를 주문 전 단계의 핵심 도메인으로 보고, 사용자별 장바구니, 수량 규칙, 금액 계산, cart API를 어떤 책임으로 먼저 세워야 하는지 정리했습니다. 또한 총액 계산은 단순 UI 계산이 아니라, 이후 주문과 결제를 지탱하는 서버 규칙이어야 한다는 점도 확인했습니다.
다음 페이지에서는 이제 이 Cart 백엔드를 storefront 장바구니 화면과 checkout 요약 UI에 연결합니다.