# 🛒ECサイトのカート〜注文処理の基本設計と実装メモ（React + Redux + Spring）
こんにちは。今回はショッピングカート機能の実装を通して学んだことを整理してみました。
---
## ✅ カートに小計（subtotal）カラムが存在しない理由
- カート情報は一時的な保存に過ぎないため、小計はDBには保存しない。
- 小計は「商品価格 × 数量」でその都度**計算**。
- 永続的に小計を保存するのは**注文アイテム（OrderItem）**のみ。
---
## ✅ 注文オブジェクトが生成されるタイミング
- ユーザーが「注文確定」または「決済完了」した時点で、
`Order`とそれに紐づく`OrderItem`が生成される。
- `OrderItem`には**当時の価格・数量・小計**を保存し、価格変更の影響を受けないようにする。
---
## ✅ 小計の扱い（フロント/バックエンド）
| 処理内容 | 方法 | 備考 |
|----------------------|------------------------------|------|
| 小計の表示 | Reduxなどフロント状態で保持 | 表示用のみなら可 |
| 正確な金額計算（注文） | **バックエンドで再計算** | 不正防止・整合性維持のため必須 |
---
## ✅ カート画面での操作設計（＋ / − / 削除）
### ① 即時APIリクエスト方式
```ts
// 例: 数量増加
fetch(`/api/cart/${productId}`, {
method: 'PUT',
body: JSON.stringify({ quantity: newQuantity }),
});
- 操作するたびにサーバーと同期
- 一貫性が高いが通信量が増える
② Reduxで保持し、まとめて送信
- フロントのみで状態管理し、「注文確定」時にまとめてPOST
- UXは良いが、サーバーとの状態ズレに注意
③ ハイブリッド方式（推奨）
- 数量変更はディバウンス（一定時間入力が止まったら送信）
- 削除ボタンは即時送信
- 多くの実務プロジェクトで採用されている手法
✅ 実装のポイントまとめ
- 小計は基本的にフロントで計算表示のみ
- 決済や注文登録の時には必ずバックエンドで検証・再計算
- UIの応答性とデータの正確性のバランスが重要
🧰 使用技術スタック
- フロント：React + Redux Toolkit
- バックエンド：Spring Boot + JPA
- データベース：PostgreSQL
✍️ 最後に
今回の実装を通じて、「何をどこで確定するか」「フロントとバックエンドの責任分離」の重要性を改めて感じました。
今後は決済APIや注文履歴の作成など、次のステップにも取り組んでいきたいと思います。