05. 入金・出金をプログラムする | ミニバンクの作り方

「残高を足す・引く」だけでは済まない、お金の操作の入口を見ます。

このページでわかること

入金は口座の金額を増やし、出金は減らします。ただし cached_balance に足し算や引き算をするだけでは、根拠となる記録が残りません。v1では financial_operations と仕訳を作り、帳簿を通して残高を変えます。

v1の入出金は、一般利用者が自由に外部の銀行口座から行う仕組みではありません。管理者側の操作として扱い、PostgreSQLの execute_deposit と execute_withdrawal が整合性を守ります。実際の銀行接続はありません。

出金では残高不足や口座状態を確認します。失敗した操作で帳簿だけが残ることがないよう、一つの取引にまとめます。

誤った操作を訂正するときは、元の記録を削除するのではなく、逆向きの取引を新たに追加します。これを reversal と呼びます。いつ何が起きたかを後から説明できる形が保たれます。

入金と出金は反対向きの計算ですが、どちらも金額が正であること、対象口座が適切な状態であること、権限のある操作であることが必要です。出金では処理時点の残高不足を拒否します。確認画面に表示した残高と確定時の残高が変わる可能性も考慮します。

v1は外部の入出金ネットワークと接続しないため、外部決済の成功・失敗通知との突き合わせは扱いません。実際の接続を追加するなら、ここが大きな設計課題です。

口座残高が1万円増えたとき、預金口座の帳簿だけに1万円を足すと、借方と貸方が釣り合いません。学習用の資金投入では、System Fundingのような相手勘定を使って同額を記録します。実際の外部入金なら、外部の資金移動とどの記録が対応するかも必要です。

「残高を増やす」という画面上の言葉と、会計上の二行以上の記録をつなげて読むのがこの章の要点です。

口座に1万円あるとき、同時に8千円の出金が二件届いたら、両方が最初の1万円を見て成功してはいけません。処理の中で対象をロックし、最新の残高を確かめてから記帳する必要があります。

管理者画面に表示した残高は判断の参考ですが、確定時の残高の代わりにはできません。この考え方は送金にも共通します。

口座から110円減ったとしても、それが送金手数料なのか訂正なのか、残高だけでは分かりません。手数料には手数料の取引と収益勘定を結びつけ、後から集計できる形にします。

手数料を伴う取引で途中失敗が起きるなら、本体だけ成功して手数料だけ失敗する状態をどう扱うか決めなければなりません。まとめるべき更新の境界を設計します。

反対仕訳を入れると残高は元へ戻せますが、履歴から元の取引を消してはいけません。利用者には「元取引」と「取消し」が分かる表示が必要です。管理者は誰が、なぜ、どの取引を訂正したか追える必要があります。

v1は訂正の記録を追加する方向を採ります。実際の運用では、取消しを許す理由や承認手順も定義することになります。

入金後に画面の残高だけが古い場合、まず再取得で直る表示の問題か、帳簿と cached_balance 自体がずれている問題かを分けます。後者なら対象の取引と仕訳を調べ、原因を記録して修復します。見た目の数字を合わせるために直接更新すると、原因の手がかりを消してしまいます。

学習用データで口座に最初の残高を与えるとき、bank_accounts の数字を直接書き換えると、帳簿からその金額を説明できません。v1の要件ではSystem Fundingとの仕訳で初期資金を作る方針です。開発用の準備だからといって、後で守りたい不変条件を破らないようにします。

同じ理由で入金・出金の管理者操作も、表示残高だけを変える近道を設けません。