PofEAA 読書会 (第6回)
# 別件ではまっていたためまとめが遅くなってしまいました。
# でもこういうのは熱いうちにまとめないといけませんね。反省。(9/17)
9-1 Transaction Script
by 中村さん
トランザクションスクリプト(TS)のクラス構成には2つの方法がある。
- 関連する領域のTSを1つのクラスにまとめる方法。これが一般的。
- TS単位に1つのクラスとする方法。GoF の Command パターン。
arton さんの Command じゃなくて Strategy じゃないの? というご意見。僕は、undo できなくても Command でいいんじゃないかなと思う。いずれにしても Strategy は違うかな。
私だけ? クライアントに対して、Command は public、Strategy は private な印象を受けるのは?
9-2 Domain Model
by 私こと id:aufheben
先日購入したばかりの BizTablet を使ってみた。表示された画面の上で操作できるわけではないので、慣れないとちょっと使いにくい。でも多少のサプライズにはなったかな?
さて、Domain Model ですが、テキストの例だけでは永続化の方法がふれられておらず、Transaction Script、Table Module との比較が不充分に思ったので、自分なりに永続化まで含めて資料を作ってみました。あと、最近このブログで書いていたレイヤの話題も。
主な議論は以下の通り。
- P.127 固有のAPIって何?
→Strategy、DB、Client、etc. 結局結論は出なかった気がする。 - Product -> RecognitionStrategy の関係が気持ち悪い。反対ではないか?
- DomainModel は DI と相性が悪い。
→Factory Injection でうまくいく気がするんだけど... - DBアクセスの責務は Service Layer ではなく、Domain Model の方が良くないか?
→ 迷うところだけど、依存関係を考えて Service Layer にした。 - ドメインロジックとアプリケーションロジックの切り分けって?
ちょっと頑張りすぎて時間を多めに使ってしまいました。
すみません。m(_ _)m ＞かくたにさん、後半の発表者の方々
9-3 Table Module
by id:afukuiさん
id:afukuiさんも実装を用意されていた。プレゼンテーション層からデータアクセス層まで DataSet を使うことで、とても簡単にアプリケーションが開発できる。
Table Module は MS の専売特許みたいな雰囲気だったけど、Java でも充分使える手法だと思う(っていうか、実際使ってるし)。
9-4 Service Layer
by id:ogijunさん
Service Layer を設けるという点では賛成意見多数。
Service Layer にも2つのバリエーションがある。
- Domain Facade
- Operation Script?
ダイコン時代に Layer Supertype は不要。
Goya の Presentation Model という名前は Application Model の方が良くないかとの意見あり。
複雑なトランザクション制御 - サーガ
by WRさん
サーガとは? ミニバッチの処理を取り消す補償トランザクション処理の実行。
WRさんのお話、自分には当面関係ないと思っていたら、いつのまにか自分の仕事につながってきた気がする。(^^;)
