Tweet
Tweet

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

ご清聴ありがとうございました。