Slide 1
Slide 1 text
トランザクションスクリプトはどこから来たのか
トランザクションスクリプトは何者か
トランザクションスクリプトはどこへ行くのか
2022/06/14 設計ナイト2022
末並 晃 @a_suenami
Slide 2
Slide 2 text
タイトルは某絵画のパロディですが
あまり深い意味はありません。（念のため）
Slide 3
Slide 3 text
自己紹介
● 末並 晃 @a_suenami
● 生息している界隈: DDDとか、TDDとか、RDBとか
● お仕事で使ってる技術スタック: Rails, React, Java
○ 最近は terraform おじさんです
● 好きな RDBMS: PostgreSQL
● 好きな制約: チェック制約
● 好きな焼肉の部位: ハラミ
● 好きな（ｒｙ
Slide 4
Slide 4 text
インターネット上での立場
Slide 5
Slide 5 text
インターネット上での立場
ひたすら焼肉をタカられるという
エンターテイメントをインターネットに提供し
ています。
（焼肉を奢るとは言ってない）
Slide 6
Slide 6 text
今日話すことになったきっかけ
Slide 7
Slide 7 text
今日話すこと
● トランザクションスクリプトはどこから来たのか
○ どういう文脈で語られるようになったのか
○ そもそも誰が言い出したのか
● トランザクションスクリプトは何者か
○ どんなものがトランザクションスクリプトと言えるのか
○ どんなものはトランザクションスクリプトと言え“ない”のか
● トランザクションスクリプトはどこへ行くのか
○ トランザクションスクリプトの問題はどのように改善できるのか
Slide 8
Slide 8 text
トランザクションスクリプトはどこから来たのか
● トランザクションスクリプトは『エンタープライズアプリケーション
アーキテクチャパターン』（PoEAA） から来ました
○ 調べてみたけどこれ以前の記述は見つからなかったので、た
ぶん PoEAA が初出
● ドメインロジックに関するパターンのひとつとして挙げられている
○ トランザクションスクリプトの他には、テーブルモジュールとドメ
インモデルがある
Slide 9
Slide 9 text
トランザクションスクリプトの利点
● ほとんどの開発者が理解できるシンプルな手続きモデルである
● シンプルなデータソースレイヤーと共にうまく機能する
○ 行データゲートウェイ
○ テーブルデータゲートウェイ
● トランザクションの境界をどのように設定するかが明らかである
○ 入力を受け取り出力を返す一連の手続きがトランザクションを
開くことから始め、閉じることで終了する
Slide 10
Slide 10 text
トランザクションスクリプトは何者か
“プレゼンテーションからの単一のリクエストを扱う各手続きによって
ビジネスロジックを構造化する”
Slide 11
Slide 11 text
トランザクションスクリプトは何者か
“単一のインラインプロシージャのコードである必要はない。
一部はサブルーチンに分離され、これらのサブルーチンは
異なるトランザクションスクリプト間で共有することができる。”
Slide 12
Slide 12 text
ドメインロジックに関するその他のパターン
“振る舞いとデータの両方を取り込んだ
ドメインのオブジェクトモデル”
“データベースのテーブルまたはビューの
すべての行のビジネスロジックを
処理する単一のインスタンス”
Slide 13
Slide 13 text
トランザクションスクリプトとは
● トランザクションスクリプトであるかそうでないかは、オブジェクトモ
デルであるかどうか…か？
○ ドメインモデルはレコード（もしくはそれに準ずる概念）に対す
る、テーブルモジュールはその集合（≒テーブル）に対する
データ抽象と考えることができる
● 何故オブジェクトモデルか？
○ カプセル化・モジュール化
○ ポリモーフィズム（多態性）
Slide 14
Slide 14 text
トランザクションスクリプトはどこへ行くのか
Slide 15
Slide 15 text
の前に
Slide 16
Slide 16 text
そもそも何故トランザクションスクリプトで
複雑なドメインロジックを実装するのが難しいのか
Slide 17
Slide 17 text
トランザクションスクリプトと複雑度
● PoEAA はオブジェクトモデルのほうが優れている前提で論が展
開されている気がする
○ 単に関心の分離が必要ということであればサブルーチンでよ
いはず
○ 現に、ある一定のレベルまではサブルーチンへの分割によっ
て解決可能だと言っている
● 一定以上複雑になった場合には、やはりカプセル化や多態性（ポ
リモーフィズム）を実現する仕組みが必要ということだろうか？
Slide 18
Slide 18 text
ユースケースと状態のもつれ
この状態がよく言われる複雑化したトランザクションスクリプト
Slide 19
Slide 19 text
サブルーチンによる構造化
共通の手続きをまとめ、ロジックの重複を緩和した状態
Slide 20
Slide 20 text
サブルーチン（を束ねたクラス）の循環依存
サブルーチンをstaticメソッドにして
それっぽいクラスにまとめた場合に起こりがち
Slide 21
Slide 21 text
オブジェクトモデルによる（？）データ抽象
ドメインモデルやテーブルモジュールはこれに近い
Slide 22
Slide 22 text
サービスレイヤーの導入
サービスレイヤーを導入し
共通の手続きはオブジェクトモデルとは別途共通化
Slide 23
Slide 23 text
ドメインロジックとアプリケーションロジック
“私を含む多くの設計者は、「ビジネスロジック」を2種類に分けるのが好きだ。
「ドメインロジック」は純粋に問題領域に関係するものであり「アプリケーションロ
ジック」はアプリケーションの責任に関係するものである。”
Slide 24
Slide 24 text
DCI
手続き・アルゴリズムの境界とデータの境界は異なり、伝統的なオブジェクト指
向ではそれを共通の機構で実現しようとしている（という問題提起）
https://digitalsoul.hatenadiary.org/entry/20100131/1264925022
Slide 25
Slide 25 text
まとめ
● トランザクションスクリプトはどこへ行くのか
○ 手続きを手続きのまま構造化する
○ オブジェクトモデルを用いてデータ抽象や多態を用いる
● 手続きとデータの境界は異なることがある
○ ビジネスロジックをドメインロジックとアプリケーションロジック
に分け、前者にデータ抽象を、後者に手続きの構造化を
○ DCI ではロールという概念を導入して、オブジェクト間のコラボ
レーションを実現する
Slide 26
Slide 26 text
ご清聴ありがとうございました。