Zenn
Closed6

100日チャレンジ day45 (Sagaパターンを使った旅行予約）

llmバックエンド100日チャレンジ
riddle_tecriddle_tec

昨日
https://zenn.dev/gin_nazo/scraps/9af3241feb10cb

https://blog.framinal.life/entry/2025/04/14/154104

100日チャレンジに感化されたので、アレンジして自分でもやってみます。

やりたいこと

  • 世の中のさまざまなドメインの簡易実装をつくり、バックエンドの実装に慣れる(dbスキーマ設計や、関数の分割、使いやすいインターフェイスの切り方に慣れる
  • 設計力(これはシステムのオーバービューを先に自分で作ってaiに依頼できるようにする
  • 生成aiをつかったバイブコーティングになれる
  • 実際にやったことはzennのスクラップにまとめ、成果はzennのブログにまとめる(アプリ自体の公開は必須ではないかコードはgithubにおく)

できたもの

https://github.com/lirlia/100day_challenge_backend/tree/main/day45_travel_saga

riddle_tecriddle_tec

了解しました！
**「旅行予約一括予約システム（Sagaパターン体験）」**の仕様案をまとめます。

Day45: 旅行予約一括予約システム（Sagaパターン体験）

概要

  • ユーザーが「ホテル」「航空券」「レンタカー」など複数サービスを一括で予約できるシステム
  • 各サービスは独立したAPIで管理され、Sagaパターンで一連の予約フローを制御
  • どれか一つでも失敗した場合は、すでに成功した予約を補償（キャンセル）する

主要機能

1. 予約フロー

    1. ユーザーが「旅行予約」を開始（旅行日程・人数など入力）
    1. サーバー側で以下を順次実行
    • ホテル予約API呼び出し
    • 航空券予約API呼び出し
    • レンタカー予約API呼び出し
    1. 途中で失敗した場合は、すでに予約済みのサービスを「補償API」でキャンセル
    1. すべて成功した場合のみ「予約確定」

2. 予約状態の可視化

  • 予約ごとに「進行中」「成功」「失敗」「補償中」「補償完了」などの状態を表示
  • 各サービスごとの予約・補償の状態も個別に表示

3. ユーザー切替

  • シンプルなUIでユーザーを切り替え、各ユーザーの予約履歴を確認可能

4. 補償処理

  • 例: ホテル予約成功→航空券失敗→ホテル予約キャンセル（補償）
  • 各サービスごとに「予約」「キャンセル」APIを用意

DB設計（イメージ）

  • users（ユーザー情報）
  • reservations（旅行予約全体、状態管理、ユーザー紐付け）
  • reservation_steps（各サービスごとの予約・補償状態、予約ID紐付け）
    • type: hotel/flight/car
    • status: pending/success/failure/compensating/compensated
    • reservation_id: 外部サービスの予約番号（あれば）

API設計（イメージ）

  • POST /api/reservations … 旅行予約開始

  • GET /api/reservations/:id … 予約詳細・進行状況取得

  • POST /api/reservations/:id/cancel … 予約全体のキャンセル（補償処理）

  • 内部API（サーバー側で呼び出し）

    • /api/hotel/reserve /api/hotel/cancel
    • /api/flight/reserve /api/flight/cancel
    • /api/car/reserve /api/car/cancel

UIイメージ

  • 予約フォーム（旅行日程・人数など入力）
  • 予約進行状況タイムライン（各サービスの進捗・補償も見える）
  • 予約履歴一覧
  • ユーザー切替UI

学びポイント

  • Sagaパターンの状態管理（進行中/補償/完了）
  • 各サービスのAPI分離と補償処理
  • 状態遷移の可視化
  • エラー発生時のロールバック体験

この仕様で進めてよろしいでしょうか？
追加したい要素や、逆に簡略化したい部分があればご指示ください。

riddle_tecriddle_tec

はい、Day45「旅行予約一括予約システム（Sagaパターン体験）」の具体的な作業計画を、ルールに沿って詳細に作成します。

Day45: 旅行予約一括予約システム（Sagaパターン体験）

作業計画（ステップ・ファイル構成・テスト方針付き）

0. 仕様確定・設計

  • 仕様・要件の最終確認
  • 画面遷移・APIフロー・DBスキーマの設計
  • PROGRESS.mdに全体工程を記載

1. プロジェクト初期化

  • template ディレクトリを day45_travel_saga にコピー
  • package.json の name を day45_travel_saga に変更
  • README.md を設計内容で上書き
  • PROGRESS.md に作業工程を記載
  • cd day45_travel_saga で作業ディレクトリ移動
  • ディレクトリ/ファイル一覧を作成

予定ディレクトリ構成

day45_travel_saga/
├── app/
│   ├── api/
│   │   ├── reservations/         # 旅行予約API
│   │   │   └── route.ts
│   │   ├── reservations/[id]/    # 予約詳細・補償API
│   │   │   └── route.ts
│   │   ├── hotel/                # ホテル予約API
│   │   │   └── route.ts
│   │   ├── flight/               # 航空券予約API
│   │   │   └── route.ts
│   │   └── car/                  # レンタカー予約API
│   │       └── route.ts
│   ├── (pages)/
│   │   ├── reservations/         # 予約一覧・詳細
│   │   │   ├── page.tsx
│   │   │   └── [id]/page.tsx
│   │   └── form/                 # 予約フォーム
│   │       └── page.tsx
│   ├── _actions/                 # サーバーアクション
│   ├── _lib/                     # ビジネスロジック
│   ├── layout.tsx
│   ├── globals.css
│   └── page.tsx
├── lib/
│   ├── db.ts                     # DB初期化・クエリ
│   └── types/                    # 型定義
├── db/
│   └── dev.db
├── PROGRESS.md
├── README.md
├── package.json
└── ...（設定ファイル等）

2. データモデリングとDB設定

  • lib/db.ts でテーブル定義
    • users
    • reservations
    • reservation_steps
  • 必要に応じて db/dev.db を削除
  • サーバ起動でスキーマ自動生成
  • テーブル作成テスト

3. APIエンドポイント実装

  • /api/reservations（POST: 予約開始, GET: 一覧）
  • /api/reservations/[id]（GET: 詳細, POST: 補償/キャンセル）
  • /api/hotel /api/flight /api/car（各サービスの予約・キャンセルAPI）
  • 各APIのエラーハンドリング
  • curl等でAPIテスト

4. Saga状態管理・補償処理

  • 予約進行中/成功/失敗/補償中/補償完了の状態遷移ロジック
  • 各サービスAPIの成功/失敗時の補償処理
  • 状態遷移テスト

5. ユーザー識別・切替UI

  • ユーザー切替用の簡易UI実装
  • ユーザーごとの予約履歴取得

6. UIコンポーネント実装

  • 予約フォーム（旅行日程・人数入力）
  • 予約一覧ページ
  • 予約詳細ページ（進行状況タイムライン付き）
  • 各サービスの予約・補償状態の可視化
  • アプリタイトル「Day45 - 旅行予約Saga体験」

7. 主要業務フロー実装

  • 予約→各サービス予約→補償処理の一連の流れ
  • UIから予約進行状況を確認できるように
  • フィードバック表示

8. デバッグ・テスト

  • API単体テスト（curl, fetch等）
  • UI動作確認（playwright等）
  • エラーハンドリング確認
  • 不要なファイル・コード削除

9. ドキュメント作成

  • README.md 更新（設計・使い方・学びポイント）
  • .cursor/rules/knowledge.mdc 更新

各ステップごとに

  • テストを実装・実施
  • テスト通過後に「day45 : step x/x <内容>」でコミット
  • PROGRESS.md に進捗記入・チェック

もし追加したい機能や簡略化したい部分があればご指示ください。

この計画でよろしければ、次回から順次作業を進めます。

このスクラップは3ヶ月前にクローズされました