智恵の和（技術知識の和）コミュの2008年5月10日講義パート議事録

これからはシンプルなドメインモデル　平瀬さん

■自己紹介
　- 平瀬さん
　- 石田さん

■ドメインモデルの位置づけ
　- EAアーキテクチャの一部
　- アーキテクチャとは
　　　アプリケーションの内部構造
　　　クラスの責務

■ドメインモデルって？
　- DBのテーブルに近いデータ構造とビジネスロジックを持つクラス
　- データの参照時に関連を自己解決する
　- Tx管理は範疇外(呼び出し側で制御する)
　　　★AutoCommitは無効にすることが前提？

■迷走する受託開発その1
　- 大手SIerまでもがアジャイルに手を出す→大抵うまくいかない
　　アジャイルで成功する為の条件
　　　開発者の高度なスキル
　　　お客様の意識改革
　　　プラクティス
　　　コミュニケーション

　- 技術力とコミュニケーションの両方を兼ね備えている開発者が少ない
　　　★技術力とコミュニケーションはどれくらいあったほうがいいのか、という定量的な基準がほしいかな。
　- 工数がかさむ

■迷走する受託開発その２
　- ハイテク依存症
　　なんでも自動テストで効率化されると思い込んでいるが・・・
　　　仕様変更の激しさ
　　　テストケースの記述の難しさ
　　　テストデータの管理の難しさ
　- あるべきレイヤ分割を考えてDIコンテナで疎結合にしているが、
　　ユニットテストしやすさ以外にメリットがない
　- Hibernateはドメインモデルの塊
　- SQLのパフォーマンス

■問題を解決しよう
　- 現実的なアジャイル
　　　高度な技術力が全員に必要なアジャイルでは、メリットが少ない
　　　若手には比較的低い品質で済む画面系を担当させる
　　　つまり、ビジネスロジックやシステムのデータ構造に対する理解は最小限にすべき
　- 最小のフレームワーク
　　　リスクを最小限にするため、複雑なFWは導入しない
　- 本質であるビジネスロジックやデータの集中管理

■ドメインモデルの重要概念
　- モデルクラス
　　データ構造とビジネスロジックを同一クラス上で表現することにより、処理が行方不明にならない
　- オブジェクトグラフ
　　データアクセスパスの隠蔽化と共通化により、ソースコード上のSQLが徹底的に削減できる
　　変更が容易になり、パフォーマンスチューニングがしやすい
　　かつ、データベースを理解している開発者が少なく済む

■オブジェクトグラフの利用(ソースコード)

　★ドメインモデルは関連(あるいは委譲)を持っているからいいってこと？

■オブジェクトグラフは何がうれしいのか？
　- モデルクラスを利用する開発者は、関連の詳細を知っている必要がない
　　画面の開発者はER図を理解する必要ない

　-　関連の理解が最小限で済む

■ドメインモデルが難しいと言われているわけ
　- 再利用性を考えすぎ
　　再利用性が高いということは、高度な抽象化であることから、設計や実装の難易度が高い
　　受託開発で作成した実装を再利用することがどれだけあるの？

　- FWが難しい
　　Hibernateを使いこなすのが難しい。オブジェクトの状態やら・・・。
　　★iBATISかS2Daoがオススメかも。
　　★あるいはSpringのJpaDaoSupportの仕組みを利用するのがいいかも。

■現実的なドメインモデル=シンプルなドメインモデル
　- Daoを使ってドメインモデルを作ろう
　　完璧なドメインモデルを作れなくても、Daoはそのまま使いまわせるため、
　　逃げ道は用意されているから安心感抜群
　- パフォーマンスの問題がでたら、その部分はDaoでSQL書いていい
　- S2DaoのN-1マッピングはいいよ。

■でも
　- 結局データベース設計もあり、インピーダンスミスマッチとか難しくない？
　　E/Rはモデルの設計から機械的に起こせる。TMを参考にした設計。
　　複雑なインピーダンスミスマッチが嫌なら継承を使わなければよい。
　- 作成するクラスの量が多い。
　　　そのため、ソースコード自動生成ツールを用意している。
　- 仕様変更に追従出来ない
　　　クラスを作りなおした方が早くない？

■オピニオン

■使った結果
　- 寄せ集め集団でも、仕様が右往左往しても混乱が発生しない
　- 上流工程と下流工程とのズレが減少
　　　お客様がモデルのクラス図をよめるようになった
　- メンバーのオブジェクト指向のスキルが大幅にアップ

★ドメインモデルの原典は、たぶんPofEAAだと思いますので、リンクを張っておきます。
　http://www.martinfowler.com/eaaCatalog/domainModel.html

コメント(1)

最初
全て
最新の40件

[1] mixiユーザー 05月11日 15:15

前野さん、議事録ありがとうございます。講習会ではどうもでした（＾＾

私の陳腐な資料とまとまりの無い話を、うまくまとめてられていて素晴らしいです。
ありがとうございます。

> - Tx管理は範疇外(呼び出し側で制御する)
> ★AutoCommitは無効にすることが前提？

ご指摘の通りです。Tx管理が必要＝AutoCommitは無効という前提です。
逆にTx管理が不要であれば、モデル層にかかわらず、システム全体で不要になるわけですから、AutoCommitを有効にして構わないでしょう。

>　- 技術力とコミュニケーションの両方を兼ね備えている開発者が少ない
>　　　★技術力とコミュニケーションはどれくらいあったほうがいいのか、という定量的な基準がほしいかな。

確かにそうですね（＾＾。私なりに考えたことを書いてみます。
技術力はプログラミング言語、フレームワーク、インフラの理解、要求からデータ構造とロジックに落とし込む能力が挙げられると思います。
コミュニケーション能力は、お客様から要求を正確に理解する能力、理解した内容をコンパクトにわかりやすくドキュメントにまとめる能力、コストに見合わない無駄な要求を削減するなどの交渉力、他の開発者にわかりやすい設計やコードが何かを考える力。そして最も大切なのはお客様や仲間と調和する協調性です。ただし、調和というのは仲良しという意味ではありません。時にはぶつかり合い、意識やスキルを高め合いながら目的を最短で達成できることを考えられる事も望まれますので、自分の意見をはっきりと伝えられる能力も含まれます。
各能力がどれくらいで十分かというのは、なかなか示すことはできないのですが、少なくとも問題が発生した際に、中心となって解決できる事が必要だと思います。例えば、OSSのフレームワークで問題が発生したら・・・フレームワークのソースコードを読んで調査する。or BBSやMLで適切な質問をする。というように、技術力もコミュニケーション力もどちらも必要になるわけです。

でも、実際、こんなスーパーマンはほとんどいないのが実情でして。。。
「プログラムを書く力」、「やる気」、「やり遂げる責任感」、「ホウレンソウがしっかりできること」、「人の話を理解しようとする姿勢」。最低限、これだけ持っていれば、プロジェクトの中で教育していけば何とかなると考えています。（これを備えているだけでも、業界的には十分スーパーマンです。。。）

> ★ドメインモデルは関連(あるいは委譲)を持っているからいいってこと？

そうですね。まずは関連を使う側に強制させることがうれしいです。これは、モデルクラスのオブジェクトが関連するデータの取得を自己解決する機構を備えるということです。
更にオブジェクト指向の理解が進むと、モデルクラスの振る舞い（メソッドを適切に設計できるようになり、複雑なロジックを単純なオブジェクトの協調で表現できるようになります。オブジェクトの協調はデータ取得の自己解決があるからこそ、スムーズになりたつわけでして、今回の説明で協調したオブジェクトグラフというのは、ドメインモデル理解のための第一歩と考えていただければと思います。

> 　　★iBATISかS2Daoがオススメかも。
> 　　★あるいはSpringのJpaDaoSupportの仕組みを利用するのがいいかも。

S2DaoはCoCで記述が少ないため大好きです（＾＾
iBATISもちょっとばかり勉強したことがあるのですが、設定を書く量が多かったような。Springは未経験に近いです。ごめんなさい。

> ★ドメインモデルの原典は、たぶんPofEAAだと思いますので、リンクを張っておきます。

その通りです。ありがとうございます。

あと、モデルの抽象化をしなかったり、適切なメソッドを持たないモデルクラスを、マーチンファウラー氏は「ドメインモデル貧血症」という風に評しています。オブジェクトグラフを作ったら、オブジェクト指向を理解してクラス設計して、貧血を解消すると、ドメインロジックの拡散によるめまいが解消して更に楽になりますよ（＾＾

・ドメインモデル貧血症
http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel

ではでは（＾＾

ログインすると、みんなのコメントがもっと見れるよ