14. ここまで学んで何が分かったのか

一つの画面の裏にある設計判断を振り返り、次の学びへつなげます。

このページでわかること

v1は残高の数字だけを信じません。帳簿を根拠とし、追記専用の履歴を残し、あとから照合できるようにしています。失敗時に全部取り消せる境界と、再送時に二重実行しない仕組みも、この考え方の延長です。

正常な送金ができるだけなら、残高を二つ更新する単純な実装でも画面上は動きます。v1で学べる核心は、二重送信、同時送金、権限のない操作、途中失敗を考えても、帳簿と残高の説明が崩れない境界を設計することです。

外部銀行との接続、実在の本人確認、より強い不正検知、バックアップと復旧、障害時の連絡、規制対応は学習用v1の外にあります。新しい機能を足す前に、どの前提が変わるかを見極めます。

たとえば外部送金は相手システムの結果が遅れて届くため、データベース内だけの一括処理では完結しません。v1の「一つのトランザクション」がどこまで有効かを考えることが、次の設計への入口になります。

帳簿、監査、冪等性、ロックは、画面だけ見れば余分に見えるかもしれません。しかし、残高の根拠を説明する、操作を再現する、再送で二重に動かさない、同時操作で使いすぎないという別々の問題に答えています。

どの仕組みが何を守るかを分けて言えるようになると、機能を追加するときにも必要な対策を選べます。

利用者の操作からAPI、データベース、帳簿、管理画面、テストまでを一つの題材でつなげて見られます。送金が成立した理由だけでなく、拒否された理由と記録の残り方まで追える点が重要です。

一方、学習用の環境であるため、実際の資金移動や外部機関との突き合わせを完成させたわけではありません。到達点を正確に捉えることが次の設計につながります。

新しい機能を追加するときは、まず「誰が使うか」「どの状態が変わるか」「どの記録が根拠になるか」「失敗や再送時にどうなるか」を確認します。たとえば外部送金なら、相手銀行の返事が遅れたり、後で取り消されたりする可能性が加わります。

v1で有効だった一つのデータベース取引だけでは、外部システムまで同時に確定できません。前提の変化から新しい設計課題を発見します。

まず一件の送金を選び、画面、API、データベース関数、仕訳、テストの順に五つのファイルを開きます。各層の役割を一文ずつ書き、送金が失敗した場合に何が残るか説明してみます。

この説明ができれば、技術名を列挙するよりも深く、システムの仕組みを理解できています。次の題材でも同じ方法で、操作と記録の関係を読めます。

残高を毎回帳簿から全件集計する方法は分かりやすい一方、件数が増えると表示が遅くなります。キャッシュを置けば速くできますが、帳簿との不一致を検知・修復する責任が生まれます。v1の設計は、帳簿を根拠にしながら表示用残高を持つという折り合いを示しています。

一つの選択で問題が消えるのではなく、別の検証が必要になることを学べます。