トランザクションスクリプトはどこから来たのか トランザクションスクリプトは何者か トランザクションスクリプトはどこへ行くのか #sekkeinight

Transcript

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