MINIBANK v1.0.0 を題材に学ぶ
v1からv4で何が変わる？
ここでの v1〜v4は学習サイトの内容を深める段階です。題材にしている MiniBank のコードは、どの段階も同じ v1.0.0 タグを参照します。v2〜v4で銀行アプリの機能やソースコードの版が変わるわけではありません。
14記事を通して、画面・API・データベース・帳簿がどうつながるかを読む。
全記事の目次 →1万円の送金を、入力から仕訳・履歴・監査まで順にたどり、失敗時も考える。
送金の道順 →本人確認、入出金、管理者の凍結、整合性チェックへ対象を広げる。
周辺機能の道順 →重要な実コード抜粋を読み、権限・一括更新・再送・失敗時のテストで説明を裏付ける。
コードの道順 →現在のサイトはこれらを一つに統合した状態です。v1・v2・v3・v4を切り替えて表示する機能や、各段階の独立した保存版はありません。
STAGE V2
1万円の送金を、画面から帳簿まで追う
山田さんの口座から佐藤さんへ1万円を送る一件を想定します。正常時の流れを読み、次に「残高不足」と「応答が届かない」を考えます。
- 画面と入力送金先・金額を入力します。ブラウザでの案内に加え、APIは
createTransferSchema.safeParseで形式を検証します。画面とAPIのコード → - APIからサービスへ
src/app/api/v1/transfers/route.tsが依頼を受け、TransferServiceがexecute_transferを呼びます。金額・送金先・冪等性キーを渡します。呼び出しのコード → - データベース内で確定
execute_transferは口座を決まった順にロックし、ロック後に冪等性と帳簿由来の残高を再確認します。その後、仕訳、取引行、残高キャッシュ、監査イベントを扱います。送金記事 → - 帳簿と履歴で結果を見る仕訳は借方・貸方が同額です。取引行は履歴の根拠になり、
cached_balanceは帳簿から再計算されます。帳簿のコード →
残高不足なら確定前に拒否されます。処理途中でエラーが起きた場合、同じデータベース取引内の変更はロールバックされます。通信だけが切れた場合は成立済みの可能性があるため、同じ冪等性キーで再試行し、履歴も確認します。
「残高と帳簿が一致する理由」は、仕訳を基準に残高を計算し、仕訳の釣り合いと一括確定をデータベースで守ることです。失敗時のテスト →
STAGE V3
送金の前後に必要な機能を追う
送金だけを読んでも、誰が口座を使えるのか、資金がどこから入るのか、管理者がどう止めるのかは分かりません。次の順番で状態と権限を見ます。
- 本人確認と口座の権限申請、審査、確認済みという状態を追い、顧客が自分の口座だけを読める RLS を確認します。セキュリティ記事 →
- 入金・出金金額の検証、口座状態、出金時の残高不足、仕訳への反映を確認します。外部決済網との接続は v1 の範囲外です。入出金記事 →
- 管理者による凍結口座凍結の前後で利用者の操作がどう変わるかを見ます。管理者画面の表示権限と、個々の操作の実行権限を分けて確認します。管理者のコード →
- 整合性チェック帳簿と表示残高の差を検知したとき、取引・口座・監査の記録をたどります。検証記事 →
v1には内部取引と管理機能があります。実在の本人確認事業者、外部銀行ネットワーク、本番の規制対応や障害運用は別途必要です。
STAGE V4
重要なコードを読み、自分で確かめる
コードを全部読む代わりに、ひとつの操作について「入力」「権限」「更新」「戻り値」「失敗時」の五点をメモします。各記事の短い実コード抜粋から、元ファイルへ進めます。
- 入力を読む
src/lib/validation/common.tsと送金APIで、円金額が文字列として検証される理由を確認します。金額のコード → - 更新の境界を読む
TransferService.tsとexecute_transferを並べ、どちらが口座・仕訳を書き換えるかを確認します。送金のコード → - 守る条件を読むRLS、仕訳の釣り合い、冪等性、ロック後の再確認がどこで実行されるかを確かめます。帳簿のコード → 権限のコード →
- テストで反証する成功だけでなく、権限不足、残高不足、同じキーの再送、同時実行、失敗時に取引行が残らないことを確認します。テストのコード →
「1万円を送ると何が保存されるか」「失敗時に何が取り消されるか」「画面の残高を帳簿から説明できるか」を、具体的なファイル名とともに説明できれば、この道順の到達点です。