メインコンテンツまでスキップ

🧩 Transaction Script

✅ このスタイルの概要​

1 つの処理（トランザクション）を 1 つの関数・スクリプトとして実装する構造スタイル。
画面や API の「1 ユースケース＝ 1 関数」というシンプルな設計で、小規模システムに向く。

✅ 解決しようとした問題​

Transaction Script は Big Ball of Mud のような混沌よりは秩序があり、
次のような現実的課題を解決するために採用されることが多い。

  • まずは動くものを作りたい
  • 要件が複雑でない
  • ドメインルールが軽く、ビジネスロジックは“処理の直列手続き”で済む
  • データ構造も単純で、アプリ内部の “表現” と “DB 構造” がほぼ一致している
  • 設計コストを最小にしたい（開発期間が短い）

✅ 基本思想・ルール​

Transaction Script は次のような特徴を持つ：

  • 各処理単位（Use Case / API Handler / バッチジョブ）ごとに関数を作る
  • ビジネスロジックはその関数内部に “直列で” 書かれる
  • データアクセスも関数内で直接呼ばれることが多い
  • Domain Model のような複雑なオブジェクトは不要
  • 他の関数との共有ロジックはできるだけ減らされる（または増やしてはいけない）

実装例のイメージ：

processOrder()
   → 入力チェック
   → 在庫確認
   → 決済呼び出し
   → 注文レコードの保存
   → 完了レスポンス

✅ 得意なアプリケーション​

  • CRUD 中心のシンプルアプリ
  • 小規模な管理画面
  • 数週間〜数ヶ月の短命プロダクト
  • データモデルと UI がほぼ一致する Web アプリ
  • 小規模スタートアップの MVP（最小実用製品）

❌ 不向きなケース​

  • ビジネスロジックが複雑で “手続き列” では表現しきれない
  • 読み取り・書き込みロジックが大量に分散していく
  • 同じ処理のバリエーションが増える
  • ステートや不変条件の制御が必要（DDD が向く領域）
  • 長期運用・機能追加が継続的に発生するプロダクト

✅ 歴史（系譜・親スタイル）​

  • Fowler の Patterns of Enterprise Application Architecture によって明確化された
  • Big Ball of Mud → Transaction Script → Layered Architecture と発展
  • 小規模 → 中規模へスケールさせる際に「限界」が現れ、
    Domain Model / Layered などが登場した

✅ 関連スタイル​

✅ 代表的なフレームワーク​

Transaction Script は特定のフレームワークに依存しないが、
“1 ユースケース＝ 1 関数” の構造を自然に誘導する場面が多い。

  • Next.js / Node.js（API Routes / Route Handlers）

    • 単一関数でリクエスト → レスポンスを完結させやすい
    • 手続き的処理が中心の小規模 API に向く

  • Laravel / Rails（Controller 内の手続き的処理）

    • 小規模 CRUD では Controller 内に処理が集まりやすく Transaction Script 化しやすい

  • サーバレス系（AWS Lambda / Cloud Functions）

    • 1 関数 = 1 処理となるため、Transaction Script と非常に相性が良い

✅ このスタイルを支えるデザインパターン​

Transaction Script 自体は “パターンをほぼ必要としないシンプル構造” だが、
以下のパターンが部分的に補助的役割を果たす。

  • Command

    • 処理単位（Use Case）を操作オブジェクトとして表現する際に利用される
    • トランザクション処理の「操作」を明確化できる

  • Template Method

    • 複数の Transaction Script 間で処理ステップが似ている場合の抽象化に向く
    • 例：共通の前処理・後処理を統一化する

  • Strategy

    • 処理の“差し替え点”が発生した場合に使用されることがある
    • 基本的には TS の守備範囲外だが、成長時に補助として現れる

✅ まとめ​

Transaction Script は、簡単なアプリケーションに最適な「現実的・実用的な」構造スタイル。

しかし成長し続けるプロダクトでは、ロジックの重複・肥大化・変更困難・テスト困難が急速に拡大する。

そのため、「スケールしない」ことを理解したうえで使うべきスタイルと言える。