状態・データ・更新単位を設計する

このレッスンの到達目標

業務上の整合条件を、保存と競合の制御につなぐ。

音声とインタラクティブ図解で学ぶ音声を再生すると、下のインタラクティブ図解と本文の段落ハイライトが連動して動きます。

TRANSACTION & IDEMPOTENCY LAB · AUDIO & INTERACTIVE

DBトランザクション境界・外部連携タイムアウト・冪等再送ラボ

明細更新途中のエラーや、会計連携APIの応答消失時に「データ不整合」や「二重計上」がなぜ起きるのか、パケットアニメーションで検証します。

データ更新と外部境界の挙動1. トランザクションなし（部分失敗）

受注明細を更新した直後にエラーが発生し、受注ヘッダー合計が旧金額のまま残った状態です。

設計・移行・運用の要点DB内部で明細と合計が300円不一致

DBのロールバックだけでは外部送信は取り消せません。連携IDによる冪等性、処理済み照会、照合（件数・金額）をセットで設計します。

値引きの適用時点と根拠を保存し、後のマスター変更で金額が意図せず変わらないようにするかを要件から判断します。受注明細と合計、請求の元データなど、同時に整合すべき項目を一覧にします。

一緒に成功すべきDB更新はトランザクションの範囲を検討します。同時更新の競合検知、ロック、再試行の扱いは別に確認します。外部送信まで同じDB操作だけで元に戻せるとは考えず、境界と副作用を整理します。

受注確定、出荷、請求確定などの状態ごとに許可する操作と権限を定めます。画面、API、バッチで同じ制約を守れる構造にし、監査記録や訂正の経路も設計します。状態の抜けや二重処理は具体例で確認します。

設計レビューでは、正常動作に加えて更新途中の失敗、競合、再実行の結果を説明します。AIに設計案を作らせた場合も、業務ルールと採用DBの制御方法に合うか、根拠資料と技術検証で確かめてください。

読了記録と習熟度の確認は別です。