PoEAA読書会 第6回参加しました

今回で2回目の参加ですが、参加者が30人以上もいて、ポジションペーパーも大量になってきました。(^_^;)

今回は9章のDomain Logic Patternsのところです。

• TransactionScript（by 中村さん）
  • 手続き型のアプローチ
  • どこへでも配置できる（サーバPage、CGI、分散セッション オブジェクト）
  • 重複しがちなコードはサブルーチン化
  • ２つの実装方法（１つのクラスで実装 or Command パタン）
    • Undoが無いので、この例はcommand パタンではなくStrategy パタンじゃないのかという意見もあり。

• DomainModel（by id:aufheben さん）
  • 振る舞いとデータを一体化している
  • 複雑なビジネス ロジックに最適
  • 慣れていないとフラストレーションがたまる
  • ２つの形式
    • シンプルな方法 - RDBテーブルと対応、Active Record
    • リッチな方法 - 継承、Strategy、GoFパタン、DataMapperが必要
  • 注意点
    • 他のレイヤとの結合
    • オブジェクトグラフの作業セット
    • ｓession State
  • Javaでの実装
    • Entity Bean 2.0 - 再帰できない、リモートよりローカルコール、テストやりにくい
    • POJO

• TableModule（by 私）
  • DomainModelとの違い
    • DomainModelはIDごとにインスタンス化、TableModuleはテーブルごとにインスタンス化
  • メリット
    • TableModuleはRDBと親和性がある
    • .NET環境ではRecordSetパタンが一般的
    • .NET環境ではUIコントロールと簡単にバインド
    • データ構造に簡単にアクセス、カラムの追加や選択、集計などが可能
  • デメリット
    • 複雑なビジネスロジックではDomainModelが良い
    • インスタンス間の直接のリレーションがもてない
    • ポリモフィズムがうまく働かない
  • いつ使うのか
    • データ構造とビジネスロジックの複雑さを考慮して
    • メンバーのスキル
    • OOA/OODの経験値

• ServiceLayer（by id:ogijun さん）
  • ビジネス ロジックとドメインモデルの間
  • データやビジネス ロジックに複数のインターフェースを提供
  • インターフェースごとにロジックを実装すると重複してしまう
  • 境界での操作の集合
    • 粗い粒度
  • ドメインロジックの複雑さを隠蔽
  • ２つの実装方法
    • Facade − ビジネス ロジックは入らない
    • アプリケーション ロジックを実装（Layer Super Type、カプセル化して委譲）
  • パブリッシュとパブリック
    • 変えてはいけないこととそうでないことの区別
    • ドメイン モデルの変更でプレゼンテーションに影響を与えない

• WRさんのサーガ
  • 補償トランザクションの考え方について
  • 補償トランザクションは赤伝
  • オンラインパッチは別ノードで行うべきか

実は話がややこしくなるので言わなかったんですが、補償トランザクションでは元に戻すだけでは済まない場合があります。例えば、ホテルの予約システムの場合、キャンセル ポリシーがあって、キャンセルを行う日が予約日に近づくと単に予約をキャンセルするだけでなく、キャンセル料が発生します。この場合、ロールバックのように元の状態に戻すだけではだめで、キャンセル料計算やキャンセル料の売り上げ計上に伴う処理も必要になります。補償トランザクションが簡単ではないのは、補償時のエラー発生以外にも、こういったビジネス ロジックを考慮した設計をする必要があるからだと思います。

... と書いたあとで、テーマはオンライン バッチにおける補償トランザクションだったことに気が付きました。上の説明は完全にズレてますね...orz

今回も熱い議論が聞けて、とても有意義でした。
飲み会では、他のシマが技術論で盛り上がっているのに対して、私のいたシマは技術以上に難しい話題（アネッサ ネタ？）で盛り上がっていました。(^_^;)
角谷さんがartonさんのSoftware FactoriesとDSLの話に、すっごく熱くなっていたのが印象的でした。

次回の読書会も、とても楽しみです。