第03章：題材ドメインを決める（在庫・注文・決済）🛒📦💳
この章の結論（1行）✨
以後の32章ぜんぶを「同じ世界の同じ単語」で話すために、ドメイン（在庫・注文・決済）を固定して、状態とルールを先に決めるよ！ 🧠🔧
3.1 なぜ「題材ドメイン」を最初に固定するの？🤔📌
分散の話って、抽象のままだと一生フワフワしがち…🥺☁️ だからこの教材では、最初に “このECっぽい世界” を作って、以後ずーっと同じ話をします🛍️✨
- 「どこがズレるとヤバい？」💥
- 「ズレてもOKなところは？」😌
- 「ズレたとき、画面にどう見せる？」🎨⏳
これを毎章、同じ題材で繰り返すから、体に染みこむよ〜🧠💕
3.2 今後ずっと使う “ミニ分散EC” の世界観 🌍🧩
主役（登場人物）👤
- お客さん（購入する人）🛒
- システム（注文を受ける）🧾
- 決済サービス（カード会社・決済APIっぽいやつ）💳
- 在庫（商品数を管理する）📦
扱う3つの領域（ここが今回のタイトル！）🧱
- 注文（Order） 🧾
- 在庫（Inventory） 📦
- 決済（Payment） 💳
この3つが“別々の部屋”にいる感じにすると、分散っぽさが一気に出るよ🏠🏠🏠✨
3.3 用語（この教材の共通語）を揃える📖✨
まずは「名詞」と「状態」を決めちゃうのが勝ち筋！🏆
名詞（Entityっぽいやつ）🧩
- Product：商品（価格・SKUなど）🏷️
- InventoryItem：在庫の実体（在庫数）📦
- Order：注文（合計金額・状態・明細）🧾
- OrderItem：注文の明細（商品・数量）🧺
- Payment：決済（状態・金額・決済ID）💳
- StockReservation：在庫の引当（予約）📌📦
ポイント：「在庫を減らす」じゃなくて「在庫を予約する」 を入れると、あとで整合性の話が超ラクになるよ😇✨
3.4 状態（ステータス）を決める：最終的整合性の“画面の言葉”になる🎨⏳
この教材は「ズレる世界」を扱うから、状態設計が主役だよ🎬✨
注文（Order）の状態案🧾
Pending：受付したよ（処理中）⏳Confirmed：確定したよ✅Rejected：だめだったよ（在庫なし/決済失敗）❌Cancelled：キャンセルされたよ🧹
決済（Payment）の状態案💳
Requested：決済開始したよ🚦Authorized：与信OK（お金はまだ確保のイメージ）✅Captured：請求/確定したよ💸Failed：失敗したよ❌
在庫引当（StockReservation）の状態案📦📌
Reserved：引当できたよ📌✅Expired：期限切れで戻したよ⌛↩️Released：キャンセルで戻したよ↩️Failed：引当できなかったよ❌
3.5 ハンズオン：ユーザー画面の状態を紙に描く✍️📝
ここ、超重要！💡 “遅れる世界” を UX で支える ための設計図になるよ🎨⏳
① まずは購入フローを1本にする🧵
例：
- 商品をカートに入れる🛒
- 注文する（注文受付）🧾
- 画面は「処理中」⏳
- あとで「確定」or「失敗」✅/❌
② 画面に出すステータス案を決める📱✨
最低限これだけでOK！👍
- 注文直後：「注文を受け付けました（処理中）」 ⏳
- 成功：「注文が確定しました」 ✅
- 失敗：「注文を確定できませんでした（在庫/決済）」 ❌
- ずっと処理中：「確認に時間がかかっています」 🕰️
③ 紙テンプレ（そのまま写してOK）📝💗
[注文ボタン押下]
↓
画面：処理中（Pending）
↓（数秒〜数十秒〜…）
(成功) 画面：確定（Confirmed）
(失敗) 画面：失敗（Rejected）+ 理由
ここでの狙い：「遅れる」を失敗に見せない 😌✨ UXの言葉があるだけで、最終的整合性が“怖くない”になるよ🫶
3.6 「どこが即時一致必須？どこは遅れてOK？」を仕分ける🧩✅
CAPの話を始める前に、業務ルールで優先順位を決めるよ⚖️✨ ここが決まると、次の章以降がスラスラ進むよ〜🚀
仕分けの基準（3つだけ覚えよ）📌
- お金：二重請求は絶対NG💸❌
- 法務/約束：やった/やってないが争点になるもの⚖️
- UX：多少ズレても“気持ちよく待てる”ならOK😌⏳
例：この教材ドメインの仕分け案🟥🟨🟩
-
🟥 即時一致がほぼ必須
- 決済の「二重請求防止」💳🧷
- 同じ注文IDの「二重確定防止」🧾🧷
-
🟨 なるべく合っててほしい（ズレると困る）
- 在庫の「残り1個」みたいな境界ケース📦⚠️
-
🟩 遅れてOK（UXで吸収しやすい）
- 「注文履歴に反映されるまで少し待つ」📜⏳
- 「在庫表示の更新（数秒〜）」👀⏳
ここでの“勝ち筋”： 🟥は頑張って守る（設計で守る） 🟩はUXで守る（表示と言葉で守る）🎨✨
3.7 以後ずっと使う「イベント」も軽く決めておく📨✨
分散は「状態」だけじゃなくて「起きたこと（イベント）」で話すと強いよ💪🔥 ここでは “名前だけ” 先に置いとく！
イベント名（例）🏷️
OrderPlaced（注文受付）🧾PaymentAuthorized（与信OK）💳✅PaymentFailed（決済失敗）💳❌StockReserved（在庫引当成功）📦📌✅StockReservationFailed（在庫引当失敗）📦❌OrderConfirmed（注文確定）🧾✅OrderRejected（注文失敗）🧾❌
ここで大事なのは「命名の統一感」だけ！✨ 実装の細かいところは後の章でやるよ🧠🔧
3.8 AI（Copilot / Codex系）で “ユーザーストーリー” を整形する🤖✨
ここはAIの得意分野〜！😻 自分のアイデアを 読みやすい仕様 にしてもらおう📝💕
ユーザーストーリーの型（これで統一）🧾
- 私は（誰として）
- 〜したい（何を）
- なぜなら（価値）
例（そのまま使える）💡
- 私はお客さんとして、注文をしたい。なぜなら、商品を購入したいから。🛒
- 私はお客さんとして、注文が処理中でも不安にならない表示がほしい。なぜなら、待っていいのか分からないから。⏳😌
- 私はシステムとして、同じ注文が2回届いても二重請求しないようにしたい。なぜなら、お金の事故は致命的だから。💳🧷
AIに投げるプロンプト例（コピペOK）📋🤖
以下の箇条書きを、ユーザーストーリー形式（私は〜として、〜したい。なぜなら〜）に整形して。
さらに「受け入れ条件（Given/When/Then）」も3つずつ付けて。
（ここに自分のメモを貼る）
- 注文後は処理中表示
- 成功したら確定、失敗したら理由表示
- 二重送信でも二重請求しない
- 在庫が足りない場合は注文を失敗にする
3.9 2026年1月時点の “道具まわり” ミニ知識（安全に進めるため）🧰🛡️
この教材は実装もするから、ツール側の“今どうなってる？”も軽く押さえとこ〜👀✨
- TypeScriptは 5.9 のリリースが案内されていて、公式のリリースノートも整備されてるよ📘✨ (Microsoft for Developers)
- Node.jsは「Current」と「LTS」が並走していて、リリース情報は公式で更新されてるよ🟢📦（例：v25系がCurrent、v24系がActive LTSとして掲載） (nodejs.org)
- VS Codeは、少なくとも 2026年1月のInsiders（v1.109） の更新情報が公開されてるよ🧪🆕 (Visual Studio Code)
- そして大事な注意⚠️：VS Code拡張（特に“AIっぽい名前”）には 悪意ある拡張が混ざるリスク が報告されてるよ😱 → 入れる拡張は「提供元」「評判」「必要権限」をちゃんと見るクセをつけよ🛡️✨ (TechRadar)
3.10 この章の完成物（チェックリスト）✅✨
この章が終わったら、手元にこれがあればOK！🧠📦
- ドメインの名詞リスト（Order/Payment/Inventory…）📖
- Order/Payment/Reservation の状態（ステータス）✅❌⏳
- 画面の状態遷移（処理中→確定/失敗）📱🧾
- 「即時一致必須/遅れてOK」の仕分け🟥🟨🟩
- ユーザーストーリー（AIで整形済み）📝🤖
- イベント名のたたき台📨🏷️
3.11 よくあるミス（先に潰す）💥🧯
- ❌ 「在庫を減らす」だけで考えちゃう → ✅ 予約（Reservation） を入れると世界が整理される📦📌
- ❌ 画面が “成功/失敗” の2択しかない → ✅ 処理中（Pending） をちゃんと居場所として設計する⏳💗
- ❌ 用語が毎回ブレる（注文=購入=オーダー…） → ✅ この章の用語を“辞書”として固定しよ📖✨
以上で、第3章は完成！🛒📦💳✨