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
6k
トランザクションスクリプトはどこから来たのか トランザクションスクリプトは何者か トランザクションスクリプトはどこへ行くのか #sekkeinight
Akira Suenami
June 14, 2022
Tweet
Share
More Decks by Akira Suenami
See All by Akira Suenami
オブジェクト指向考古学 〜人類は再びDCIの夢を見るか〜
a_suenami
5
2.2k
値と属性の話
a_suenami
0
200
ドメインモデラーにとって受託開発であることは制約なのか?
a_suenami
1
1.4k
異なるモデリングパラダイムから見るモデリングの勘所 #ooc_2020
a_suenami
2
3k
マルチパラダイムモデリング 〜異なるモデリングパラダイムから見るモデリングの勘所〜 #PHPerKaigi
a_suenami
0
3.8k
“ユーザーファースト”の功罪 〜分析と実験によるアーキテクチャ設計〜 #bpstudy
a_suenami
4
1.3k
ドメインモデルのつくり方 #5000dai
a_suenami
16
4.8k
ビジネスの構造を扱うアーキテクチャとユーザとの接点を扱うアーキテクチャ #builderscon
a_suenami
46
11k
すえなみチャンスからの重要なお知らせ #すえなみチャンス暑気払い
a_suenami
0
800
Other Decks in Technology
See All in Technology
Moved to https://speakerdeck.com/toshihue/presales-engineer-career-bridging-tech-biz-ja
toshihue
2
730
関東Kaggler会LT: 人狼コンペとLLM量子化について
nejumi
3
570
PL900試験から学ぶ Power Platform 基礎知識講座
kumikeyy
0
130
技術的負債解消の取り組みと専門チームのお話 #技術的負債_Findy
bengo4com
1
1.3k
Amazon S3 Tablesと外部分析基盤連携について / Amazon S3 Tables and External Data Analytics Platform
nttcom
0
130
組織貢献をするフリーランスエンジニアという生き方
n_takehata
1
1.3k
ホワイトボードチャレンジ 説明&実行資料
ichimichi
0
130
転生CISOサバイバル・ガイド / CISO Career Transition Survival Guide
kanny
3
960
エンジニアのためのドキュメント力基礎講座〜構造化思考から始めよう〜(2025/02/15jbug広島#15発表資料)
yasuoyasuo
16
6.5k
君も受託系GISエンジニアにならないか
sudataka
2
420
Oracle Cloud Infrastructure:2025年2月度サービス・アップデート
oracle4engineer
PRO
1
190
RECRUIT TECH CONFERENCE 2025 プレイベント【高橋】
recruitengineers
PRO
0
150
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3k
Why You Should Never Use an ORM
jnunemaker
PRO
55
9.2k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
46
2.3k
Automating Front-end Workflow
addyosmani
1368
200k
Into the Great Unknown - MozCon
thekraken
35
1.6k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
133
33k
Music & Morning Musume
bryan
46
6.3k
Building an army of robots
kneath
303
45k
Designing for humans not robots
tammielis
250
25k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
33
2.1k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
27
1.9k
Fashionably flexible responsive web design (full day workshop)
malarkey
406
66k
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 ではロールという概念を導入して、オブジェクト間のコラボ レーションを実現する
ご清聴ありがとうございました。