고객이 구매 버튼을 누른 순간부터 판매자 통장에 돈이 들어가기까지의 거래 시스템. 주문 · 결제 · 이행 · 정산이 각자 상태를 갖고 이벤트로 이어진다
거래를 모델링하고, 서버가 금액을 정한 주문서로 주문을 받아, 사가로 재고 · 혜택 · 결제를 묶는다
주문서 → 주문 접수 → 사가가 운영 commerce 앱에서 돈다. 운영 주문은 데모 9건이고 사가는 완료 6 · 실패 3 이다(2026-10-12 확인)
PG 를 통해 돈을 잡고(승인) 청구하고(매입) 돌려준다(무효 · 환불). 가장 비싼 버그는 실패가 아니라 결과를 모르는 상태다
결제 상태 머신 · 멱등 · 재조회 · 대사가 운영에서 돈다. 상대는 실제 PG 가 아니라 항상 승인하는 모의 PG 다 — 운영 결제 6건이 전부 mock- 키다(2026-10-12 확인)
결제된 주문을 출고 · 배송하고, 취소 · 반품 · 교환을 새 레코드로 처리하고, 구매 확정으로 정산 대상을 확정한다
이행 주문은 사가가 만들지만 피킹부터 배송 완료까지는 판매자 · 어드민이 손으로 넘긴다. 송장 · 택배사 연동은 없다. 클레임 · 구매 확정은 운영에서 돈다 — 환불 완료 클레임 2건(2026-10-12 확인)
돈의 움직임을 추가 전용 원장에 복식부기로 적고, 판매자별 지급액을 계산해 지급하고, PG · 원장 · 주문을 대사한다
원장 · 정산서 · PG 대사가 운영에서 돈다 — 원장 35줄의 차변 · 대변 합이 0, 정산서 1장 지급 완료. 지급은 모의 송금이고 세금 · 증빙은 없다(2026-10-12 확인)
결과 미상 결제 · 대사 불일치 · DLT 메시지 · 멈춘 사가는 자동화 뒤에도 남는다. 어디에 쌓이고 누가 어떻게 처리하는지까지 설계한다
주문 · 결제 · 혜택 · 정산 · 재고 · 이행 스키마마다 운영 이슈 테이블이 있고 DLT · 멈춘 사가 · 대사 불일치를 쌓는다. 운영자는 어드민에서 재시도 · 종결한다. 지금 쌓인 이슈는 0건이다(2026-10-12 확인)