PofEAA読書会第6回

event

引越し作業を行っていたので、今回は途中からの参加でした。雨でずぶ濡れの状態で会場に入ったときにはTransaction ScriptとDomain Modelは既に終了していました。Domain Modelなどはかなり議論が盛り上がったらしいのですが…残念です。ということで、メモはTable Moduleからです。

Table Module (発表 id:afukuiさん)

自分の理解

一つのインスタンスでテーブルの全ての行に関するビジネスロジックを担当する。基本的には1テーブル1クラスだが、行に関するアイデンティティを持たない。つまりDomain Modelのように1行1アイデンティティとはならない。データベースの構造が複雑でDomain Modelへのマッピングが難しい場合などに効果を発揮し、また既にデータベースがある場合に親和性が高い。要するにデータベースセントリックなアプローチ。

主にRecord Setパターンと組み合わせられる。また、Table Data Gatewayパターンと組み合わせて使用する方法のアドバンテージとディスアドバンテージ(p127,128)も記述されている。

pro
  • テストはその場でテーブルにデータを入れることで簡単にできる → 意外に良いテススタビリティ
  • 物理テーブルの詳細には依存していない → カラムの追加等からは実はそんなにダメージを受けない
con
id:afukuiさんのサンプルコード & デモ

MSのDB系技術の紹介でした。説明が上手いなぁ。ポトペタっぽい感じで効率良く開発できそうなイメージ。Delphiに近いらしいです。
MS系のライブラリは、割り切りかたが上手いというか、80%を満たすための取捨選択が上手いなと感じます。


Table Moduleのまとめ
  • .NETではTable Moduleパターンが楽
  • Domain ModelとTable Moduleのどちらを採用するか検討する必要がある
MS系のストアドプロシージャ開発事情

T-SQL書ける人がいれば…

Service Layer (発表 id:ogijunさん)

自分の理解

application logicとdomain logicを分離するか否かでデザインが分かれる。
この問題により、実装には二つのバリエーションができる。

domain facade
thin facadeをDomain Modelの上に敷くだけ。facade自身はビジネスロジックを実装せず、Domain Modelが全てのビジネスロジック(application logic + domain logic)を実装する。
operation script
application logicを実装するthicker classesの層をDomain Modelの上に配置する。domain logicはDomain Modelに任せ、application logicはoperation script(例えば"Service"で終わる論理的な単位で区切られたクラス群)が担う。

PofEAA本に書いてあったのはEJB2.0のLocal InterfaceのStateless Session Beanでoperation script型のService Layerを作成し、POJOで構成されているDomain Modelにdelegateする方法。若干賞味期限切れ。

Service Layer PatternとSession Facade Patternの違いは視点。Session FacadeはEJBのリモート問題を克服するためのデザインパターン。Service Layerはduplicationを避けreusabilityを上げるためのアーキテクチャパターン。

会場で出た意見
  • application logicはワークフローともとらえられる
  • Service Layerにはトランザクション境界としての意味もある
  • publishしたものを明示的に示すレイヤは便利かもしれない。というか、みんなやっていることではないのかという意見が見られました。

『.NETエンタープライズWebアプリケーション開発技術大全 Vol.5　トランザクション 設計編』第3部 複雑なトランザクション制御のサマリ (発表: WRさん)

いつもながら、WRさんのバッチ設計の話はわくわくします。

サーガ

要するに逆トランザクションのあるバッチのことか? → 違う(補償トランザクション)

さらにいえば、補償トランザクションがなくても、ショートバッチの連続をサーガと言うらしい。
サーガを前提にすることは設計に影響を及ぼすということ(「意味的に打ち消す」とは何か?)


補償トランザクションとは

既にコミットされた作業を「意味的に打ち消す」プログラム

  • 場合によってはキャンセル
  • 場合によっては引き算
  • 最後には人間系で「運用で回避」 → オペレータに泣きつく
オンライン型バッチとロック
  • 裏でOLTPが走っているので、ロックが競合する可能性を考える必要がある
  • サーバカーソルを気軽に使ってはならない
    • セット指向で行こう
バッチを走らせるホストを別マシンにするか同じマシンにするか

CPU負荷がどのくらいかで決めるといい

  • 夜間バッチは同じマシン
  • オンラインバッチは違うマシン?

懇親会

仕事の話をしたり、artonさんとコード生成の話をしたり、kdmsnrさん&id:bakockさんとGTDの話をしたり。きしださんともひさしぶりにお会いして、フィジカルの話で盛り上がりました。