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