Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
トランザクションスクリプトはどこから来たのか トランザクションスクリプトは何者か ト...
Search
Akira Suenami
June 14, 2022
Technology
14
6.5k
トランザクションスクリプトはどこから来たのか トランザクションスクリプトは何者か トランザクションスクリプトはどこへ行くのか #sekkeinight
Akira Suenami
June 14, 2022
Tweet
Share
More Decks by Akira Suenami
See All by Akira Suenami
可変性を制する設計: 構造と振る舞いから考える概念モデリングとその実装
a_suenami
9
1.9k
オブジェクト指向考古学 〜人類は再びDCIの夢を見るか〜
a_suenami
5
3.1k
値と属性の話
a_suenami
0
250
ドメインモデラーにとって受託開発であることは制約なのか?
a_suenami
1
1.5k
異なるモデリングパラダイムから見るモデリングの勘所 #ooc_2020
a_suenami
2
3.2k
マルチパラダイムモデリング 〜異なるモデリングパラダイムから見るモデリングの勘所〜 #PHPerKaigi
a_suenami
0
3.9k
“ユーザーファースト”の功罪 〜分析と実験によるアーキテクチャ設計〜 #bpstudy
a_suenami
4
1.4k
ドメインモデルのつくり方 #5000dai
a_suenami
16
4.9k
ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ #builderscon
a_suenami
46
12k
Other Decks in Technology
See All in Technology
Webアプリケーションにオブザーバビリティを実装するRust入門ガイド
nwiizo
7
850
Evolución del razonamiento matemático de GPT-4.1 a GPT-5 - Data Aventura Summit 2025 & VSCode DevDays
lauchacarro
0
210
[ JAWS-UG 東京 CommunityBuilders Night #2 ]SlackとAmazon Q Developerで 運用効率化を模索する
sh_fk2
3
430
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
380k
「全員プロダクトマネージャー」を実現する、Cursorによる仕様検討の自動運転
applism118
21
11k
Terraformで構築する セルフサービス型データプラットフォーム / terraform-self-service-data-platform
pei0804
1
180
Language Update: Java
skrb
2
300
【NoMapsTECH 2025】AI Edge Computing Workshop
akit37
0
210
AIエージェントで90秒の広告動画を制作!台本・音声・映像・編集をつなぐAWS最新アーキテクチャの実践
nasuvitz
0
120
【初心者向け】ローカルLLMの色々な動かし方まとめ
aratako
7
3.5k
AWSを利用する上で知っておきたい名前解決のはなし(10分版)
nagisa53
10
3.2k
Practical Agentic AI in Software Engineering
uzyn
0
110
Featured
See All Featured
How GitHub (no longer) Works
holman
315
140k
The Pragmatic Product Professional
lauravandoore
36
6.9k
Faster Mobile Websites
deanohume
309
31k
4 Signs Your Business is Dying
shpigford
184
22k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
Context Engineering - Making Every Token Count
addyosmani
3
49
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
A designer walks into a library…
pauljervisheath
207
24k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
139
34k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.2k
Transcript
トランザクションスクリプトはどこから来たのか トランザクションスクリプトは何者か トランザクションスクリプトはどこへ行くのか 2022/06/14 設計ナイト2022 末並 晃 @a_suenami
タイトルは某絵画のパロディですが あまり深い意味はありません。(念のため)
自己紹介 • 末並 晃 @a_suenami • 生息している界隈: DDDとか、TDDとか、RDBとか • お仕事で使ってる技術スタック:
Rails, React, Java ◦ 最近は terraform おじさんです • 好きな RDBMS: PostgreSQL • 好きな制約: チェック制約 • 好きな焼肉の部位: ハラミ • 好きな(ry
インターネット上での立場
インターネット上での立場 ひたすら焼肉をタカられるという エンターテイメントをインターネットに提供し ています。 (焼肉を奢るとは言ってない)
今日話すことになったきっかけ
今日話すこと • トランザクションスクリプトはどこから来たのか ◦ どういう文脈で語られるようになったのか ◦ そもそも誰が言い出したのか • トランザクションスクリプトは何者か ◦
どんなものがトランザクションスクリプトと言えるのか ◦ どんなものはトランザクションスクリプトと言え“ない”のか • トランザクションスクリプトはどこへ行くのか ◦ トランザクションスクリプトの問題はどのように改善できるのか
トランザクションスクリプトはどこから来たのか • トランザクションスクリプトは『エンタープライズアプリケーション アーキテクチャパターン』(PoEAA) から来ました ◦ 調べてみたけどこれ以前の記述は見つからなかったので、た ぶん PoEAA が初出
• ドメインロジックに関するパターンのひとつとして挙げられている ◦ トランザクションスクリプトの他には、テーブルモジュールとドメ インモデルがある
トランザクションスクリプトの利点 • ほとんどの開発者が理解できるシンプルな手続きモデルである • シンプルなデータソースレイヤーと共にうまく機能する ◦ 行データゲートウェイ ◦ テーブルデータゲートウェイ •
トランザクションの境界をどのように設定するかが明らかである ◦ 入力を受け取り出力を返す一連の手続きがトランザクションを 開くことから始め、閉じることで終了する
トランザクションスクリプトは何者か “プレゼンテーションからの単一のリクエストを扱う各手続きによって ビジネスロジックを構造化する”
トランザクションスクリプトは何者か “単一のインラインプロシージャのコードである必要はない。 一部はサブルーチンに分離され、これらのサブルーチンは 異なるトランザクションスクリプト間で共有することができる。”
ドメインロジックに関するその他のパターン “振る舞いとデータの両方を取り込んだ ドメインのオブジェクトモデル” “データベースのテーブルまたはビューの すべての行のビジネスロジックを 処理する単一のインスタンス”
トランザクションスクリプトとは • トランザクションスクリプトであるかそうでないかは、オブジェクトモ デルであるかどうか…か? ◦ ドメインモデルはレコード(もしくはそれに準ずる概念)に対す る、テーブルモジュールはその集合(≒テーブル)に対する データ抽象と考えることができる • 何故オブジェクトモデルか?
◦ カプセル化・モジュール化 ◦ ポリモーフィズム(多態性)
トランザクションスクリプトはどこへ行くのか
の前に
そもそも何故トランザクションスクリプトで 複雑なドメインロジックを実装するのが難しいのか
トランザクションスクリプトと複雑度 • PoEAA はオブジェクトモデルのほうが優れている前提で論が展 開されている気がする ◦ 単に関心の分離が必要ということであればサブルーチンでよ いはず ◦ 現に、ある一定のレベルまではサブルーチンへの分割によっ
て解決可能だと言っている • 一定以上複雑になった場合には、やはりカプセル化や多態性(ポ リモーフィズム)を実現する仕組みが必要ということだろうか?
ユースケースと状態のもつれ この状態がよく言われる複雑化したトランザクションスクリプト
サブルーチンによる構造化 共通の手続きをまとめ、ロジックの重複を緩和した状態
サブルーチン(を束ねたクラス)の循環依存 サブルーチンをstaticメソッドにして それっぽいクラスにまとめた場合に起こりがち
オブジェクトモデルによる(?)データ抽象 ドメインモデルやテーブルモジュールはこれに近い
サービスレイヤーの導入 サービスレイヤーを導入し 共通の手続きはオブジェクトモデルとは別途共通化
ドメインロジックとアプリケーションロジック “私を含む多くの設計者は、「ビジネスロジック」を2種類に分けるのが好きだ。 「ドメインロジック」は純粋に問題領域に関係するものであり「アプリケーションロ ジック」はアプリケーションの責任に関係するものである。”
DCI 手続き・アルゴリズムの境界とデータの境界は異なり、伝統的なオブジェクト指 向ではそれを共通の機構で実現しようとしている(という問題提起) https://digitalsoul.hatenadiary.org/entry/20100131/1264925022
まとめ • トランザクションスクリプトはどこへ行くのか ◦ 手続きを手続きのまま構造化する ◦ オブジェクトモデルを用いてデータ抽象や多態を用いる • 手続きとデータの境界は異なることがある ◦
ビジネスロジックをドメインロジックとアプリケーションロジック に分け、前者にデータ抽象を、後者に手続きの構造化を ◦ DCI ではロールという概念を導入して、オブジェクト間のコラボ レーションを実現する
ご清聴ありがとうございました。