ドメインモデル VS トランザクションスクリプト
■ このスレッドは過去ログ倉庫に格納されています
最近携わったプロジェクトのアーキテクチャは皆、トランザクションスクリプト。
SQLがわんさか書かれた後に、DBの変更が頻繁に行われるので、生産性が著しく下がる。
PofEAAで解説されているドメインモデルでどうして実装しないんだろう？
俺が身近な人に聞いた理由：
１．難解なモデリングをするイメージがあるから（アナリシスパターンのせいか？）
２．どうすれば実現できるかわからないから（アーキテクチャが複雑になるから？）
３．業務アプリにドメインモデルは向かないから（イベントドリブンではないから？）
４．Hibernate(EJB3)が重厚すぎてトラブルが起きたときに怖いから（フレームワークのノウハウがないから？）
５．画面毎に実装させないと作れないから（開発者がへぼいから？）
俺はHibernateを使わずにDAO＋リッチなORマッピング処理を自動生成する方法
（Ruby On RailsのActiveRecordみたいなかんじかな）で開発するのが好きで、
それを使ったプロジェクトでは実際に、生産性も保守性も高いと思うんだけど。。
どう思う？ >>1
>PofEAAで解説されているドメインモデル
なにこれ。 >>2
ドメインモデルとは「エンタープライズアプリケーションアーキテクチャパターン」という本に出てくる
ドメイン（ビジネス）ロジックのアーキテクチャパターンです。 このスレって結局
フルO/Rマッピングかそうでないかってことを言いたいの？ >>1
単純に世の中勉強しない馬鹿ばかりだからじゃない？
Eric EvansのDomain Drviven Designはもう読んだ？
>>7
全然違うよ。 DDDはオブジェクト広場の2007年のバックナンバーに解説記事があるから、先に読んでおくといいかもしれない。
ttp://www.ogis-ri.co.jp/otc/hiroba/index.html >>7
フルO/Rマッピングが何を指すのかがちょっとわからなかったので、YES、NOといえないのですが、
RDBのロウを継承構造のオブジェクトにするだのといった、変換についての話はどうでもいいです。
ドメインモデルかトランザクションスクリプトか？という問いたいのは、
・ドメインモデルがわかるかわからないか
・ドメインモデルを使ってるか使ってないか
・ドメインモデルが好きか嫌いか
理由を含めて知ることで、トランザクションスクリプトとドメインモデルの理解が深まるのではないかなぁ。。と思いまして。
>>8
リーダーとかアーキテクトしてる人は少なくとも勉強してるんじゃないのかな？
DDDは流し読みしたよ。
2章までは楽しく読めたんだけど、それ以降はテストコードばっかり
書かれていて、実装の全体像が明示されていないから、わかりにくいと思った。しかも.Netだし。。
考えるネタにはなるけど、これを読んでドメインモデルのシステムを作るのは
無理じゃない？
僕はDAO＋自前のOR変換＋レイジーロードのアーキテクチャで作っておいて、
チューニングが必要な所をイーガーロードにしていくので、エバンスさんとは好みが違うから余計に
否定的に思ってしまうのかも。 >>8
ごめん、DDDを思いっきり勘違いしてました。
「ドメイン駆動」がDDDの邦訳版だと思っていたんだけど、違うんですね。
ちょっと調べてきます。 ということで、11に書いてあるコメントは
「ドメイン駆動」にたいするものでした。すまん。。 DDDをAmazonで購入しました。
早速明日読んでみます。
勘違いに気づかせてくれた8さん、ありがとうございました。 現場のヒエラルキーを反映してるからしょうがないと思うYo >>14
いえいえ。
DDDはまだ日本語に翻訳された版がないので、英語に弱いと割と読むの、大変かも。
PofEAAは日本語に翻訳もされてるよね。 >>16
読んでます。が。。。使われている英語難しいですね〜（＾＾；
ひたすらわからない単語の意味を本に書きこんでいますが、
文章にしたときに意味がわからない事が多々あります。
でも、とにかく読まないとドメインモデルを語れなさそうなので、
地道に読んでいきますね。 >>16
もしよろしければDDD読んだ感想をお聞かせいただけますでしょうか ドメインモデルとトランザクションスクリプトについての説明と
それぞれどのような場面で有効なものなのかを書けや。 >>20
＞ドメインモデルとトランザクションスクリプトについての説明と
＞それぞれどのような場面で有効なものなのかを書けや。
簡単に言うとトランザクションスクリプトは手続き型だね。
手続き型なんて、今さらなんで議論してるかって、エンタープライズアプリがいつまで経っても手続き型から脱却ができないから。
ドメインモデルは。。。
まぁ皆さん勉強しましょう！ ……全然わかんね。
取り敢えず一番理解しやすかった説明はこんなんだが、こういうことなのか？
ttp://csharper.blog57.fc2.com/blog-entry-170.html
要するにこれまでデータのまとまりでしかなかったEntityがLogicも包含すると。
そんな簡単な訳ねーよな。 >>22
ドメインモデル貧血症の理解は入り口に過ぎず。
2chで理解しようってのは無理なんじゃ？ >>22
>EntityがLogicも包含すると。
アーキテクチャとしての違いの基本はそうです。つまりオブジェクト指向にするということです。
僕の理解では、アーキテクチャとしての大きな違いは、関連する情報の取得方法だと思います。
関連とは手続き型でいうと構造体に別の構造体の変数を持っている感じです。
手続き型であるトランザクションスクリプトでは、ServletやActionやServiceやLogicといった
処理専門のクラスがDaoを呼び出した結果を、この構造体にデータを詰め込みます。
当然ながら詰め込んでいない構造体のデータは参照しても値が取得できません。
例えば、Employee has Department has Companyという構造だとして、
処理専門のクラスがEmployeeとDepartmentしかデータを詰め込んでいない場合、
(Employeeのインスタンス)e.department.companyはnullになってしまいます。
一方、ドメインモデルも同じような構造をModelクラスで実装するのですが、
関連するModelインスタンスにデータを詰め込む処理は、Modelクラスの中に実装します。
例えば関連する情報を参照された際にModelクラスのゲッター内でDaoを呼び出します。
これにより関連する情報を無限に辿ることができるネットワークが構築できます。
例で言うと、処理専門のクラスがEmployeeのインスタンスを取得した後、
（Employeeのインスタンス）e.getDepartment().getCompany()を実行するだけで結果が取得できます。
このように無限に関連を参照できる構造自体がドメインモデルではありませんが、必須なアーキテクチャです。
じゃあドメインモデルは何かというと、この無限に辿れる構造のModelクラスにビジネスロジックを実装したものです。
これで何が改善されるのかというと
・関連するデータを無限に辿れるため、画面の変更に強い。
・Modelクラス郡でカプセル化された中にビジネスロジックが記述できるため堅牢になる。
・Modelクラスを現実世界に近い状態で表現できる。
・画面毎にSQLを記述する量が減るため分業しやすい。
逆にデメリットとして
・アーキテクチャが複雑になる傾向がある。
・実際には完全なカプセル化は無理なので、ある程度開発ルールで縛る必要がある。
・単純に実装するとパフォーマンスが悪くなる。
・オブジェクト指向がわからない人にはModelクラスを全く設計も実装もできない。
21さんが言うように、現状、最後のデメリットが一番のネックで広まらないのかもね。。
>>26
少し論点が特定のものに行き過ぎてる。
Martin FowlerのGetterEradicatorという記事をご覧あれ。 >>23
取り敢えずAmazonでDDD注文してみた。英検準二級の俺じゃ辛そうだがw
>>1
分かりやすい例ありがと。
「蜘蛛の巣のような関連」の実際的な意味としてはそういうことなのか。
ttp://capsctrl.que.jp/kdmsnr/wiki/PofEAA/?DomainModel
>>28
> As a result it's still common to see procedures
> that pull data out of an object to do something,
って部分でCOBOLを思い出した。
つか、分かったと思っても、分かったつもりになってそうで怖い。
俺の脳みそじゃ無理っぽ。
こういうのの専門PMのプロジェクトで下で実例みさてもらいたいもんだ。 >>28
ご意見ありがとうございます。
GetterEradicatorを読んでみました。
26の説明がpublicなゲッターを用意しないとドメインモデルが構築できない
と誤解を招くということですね。ごめんなさい。
ところで、GetterEradicatorを読んでどうもしっくりきません。
ドメインモデルはビジネスロジックをOOPで実装することですから、カプセル化が
重要なこともわかります。ドメインロジックのメソッドだけが公開されるべきだと。
でも、実際にシステムを作ってみると、関連を辿って画面に表示するだけの
処理がかなりの割合を占めているし、更新処理でDaoに関連する情報を
公開する必要があるので、要件としても、アーキテクチャ的な制約としても
publicなゲッターを用意せざるをえないと思うのです。 >>30
Martin Fowlerを超えた思考ですね。
笑 >>30
いきなり制約から考えるより、まずはどうあるべきかを考える方がよいですよ。
日本人は、言語やフレームワークは使うものと思いがちですが、理想のためにはルールを変えてしまえばいいのです。 英語難しい。パンツのシートで空を飛ぶってなんだチクショウ。 >>32
アドバイスありがとうございます。
確かに経験則にとらわれてしまうのはよくないですね。
カプセル化をするには、プレゼンテーション層向けのインターフェースを
用意して、それを使わせるルールにするのが一番簡単だと思いました。
>>33
あはは（＾＾；独特な言い回しが多いので理解するの難しいですね。 >>34
自己レスです。
JSTLとかのTaglibはリフレクションしまくりで、インターフェースを
経由できないから結構穴が大きいですな。 ドメインモデルにはJavaよりアクセス制御が柔軟な言語を
選ぶべきなのかな。。 >>1
まずは画面やデータベースを考えず、ドメインだけを考えた場合の理想的な形を考えてみたらどうですか？
英語と日本語の壁が大きすぎるのだろうな・・・
ネイティブの人はいいな。
まじめに技術的プログラミングが出来て。
日本なんか、作業だからなｗ
何も考えちゃいない。
物が来た→処理。 >>37
理想的な形というのは、
画面やアーキテクチャを無視して、理想的なドメインのモデリングをせよということですか？
それとも、ドメインモデルを中心にして考え直せば、理想的なアーキテクチャが導き出せるということですか？ 伸びないなー。
ネタ投下。
こないだ新規システムでアーキテクトやらせてもらえたから、ドメインモデルでやったんだ。
ASP.NET/C#2.0な構成。
俺は最初にコア部分作って後は別の人（外注）だったんだが、出来上がったもの見て落ち込んだ。
テストケースが空メソッドだらけな上にドメイン貧血症っていうかほとんどbean。
コーディングは各々の裁量に任せてたから、結局は俺の指示に不備があったんだと思うんだが、まぁそれはいいとして。
ドメインモデルで組まれたプロジェクトが上手く回った経験あるやついたら聞きたいんだが、末端のコーダーまでドメインモデルのなんたるかを知ってないとうまく回らんかな？
仮に知らなくてもいいって場合でも遵守させることとかあったら聞きたい。 >>42 俺も興味あるんだけど、誰も答えられないのかな。
海外のサイトとかプロジェクト見ていると
日本の平均的な技術者のレベルが低いなぁと常々思う。 ウチの会社の社内SE兼PGは大体何を作らせても、
一カ所のプログラムのみが肥大化することが多い。
必要な業務処理に対して、
その全体を一つの関数なりメソッドなりに収めようとするから
いわゆるトランザクションスクリプト的な作りになっちゃうんだよね。
書く奴曰く、その方が見通しが良くて判りやすくシンプル、だそうな。
>>45
機会があったら保守についてどう考えてるか聞いてみてくれ。 それはそもそもトランザクションスクリプトと呼べるのか、と。 そいつにとって
「その方が見通しが良くて判りやすくシンプル」
なんだったら、そっちの方が保守性高くね？
>>37で理想的な形の導出って話が出てるけど、今、そこに悩んでる。
理想形がわからない。
どうしても帳票とドメインオブジェクトのリンクを考えてしまう。
DDD読んでても「いや、だから帳票どうすんだよ帳票」とか考えてしまう。
といって、帳票をベースにしてしまうと双方向参照が生まれやすいし、
正直、オブジェクト指向的じゃないと思う。
でも帳票ベースじゃないと、画面表示で死ぬ。
うーん、帳票どうすればいいんだよ。
特に普通に組んだらLEFT JOINが8回位発生しそうな管理帳票。難しい…。 >>52
ドメインに特化して、データを構成させるのだから、
ドメインをまたがった帳票を作ろうとすれば、おのずと外部結合が多発するのは仕方ないと思うよ。
そのデメリットをもってしても、拡張しやすいデータ構造には勝てないと思う。
どうしても、外部結合の多発を嫌うのなら、ドメイン単位でビューを作ってやれば、見た目はすっきりするかもしれない。
ドメイン内では、内部結合になるだろうから。
そこまで大げさなものが不要であれば、derived-table（inline view)にするのとかかね。 >>52
常にドメインモデルマンセーにするのではなく使い分けも肝心かと。
帳票系は出力内容・タイミング（日次、週次、オンデマンド）にもよるが、ドメインモデルとは別に帳票用の非正規化したテーブル（パフォーマンスが許すならビューでもよい）を作成したほうがシステムとして美しい場合もある。
どうしてもドメインモデルをそのまま帳票に当て込みたい場合は、粗結合を極限まで追求したコンバーターなどを作成し、オブジェクトグラフの変換を簡易化する方向にパワーを使った方がいい。
帳票を問題としてあげてるが、例えば他システム連携などでもおそらく帳票と同様の問題が発生するわけで、もうこれはケースバイケースで、モデラーのセンスを信じるしかない。投げやりな回答で申し訳ないが。 >>42
コアのコードがイマイチなのが原因かもしれない。
プロジェクトの規模によるが、外注さんは原則としてコピペでプログラムを作成する。
であればコアのコード(フレームワーク部分、ドメイン、フレームワークを使ったプロトタイピング)がドメインモデルを意識したプロジェクト構成、
レイヤリング、パッケージング、コーディングスタイルになっていれば
必然的に外注さんコードもそれに準じることになる。
もう一度自分の作ったコアなコードを見直した方がいい。
それでも、コアのコードに絶対の自信があり、外注さんのスキルが一方的に低いというのであれば、
コードレビュー・ペアプロを通して教育するしかない。
ただ、これまでの経験上外注レベルの低さに苦言をいうアーキテクトは
大抵フレームワークのなんたるかをわかっていない低スキルの輩が多かった。
>俺はHibernateを使わずにDAO＋リッチなORマッピング処理を自動生成する方法
>（Ruby On RailsのActiveRecordみたいなかんじかな）で開発するのが好きで、
>それを使ったプロジェクトでは実際に、生産性も保守性も高いと思うんだけど。。
私もこれに関しては死ぬほど悩んでいる。
hibernateでオブジェクトのグラフ構造とDBの表構造をマッチングするのはOK。これについては100%生産性が高いといえる。
しかし、真にドメインドリブンアーキテクチャを追求した場合、1次キャッシュによるユニットオブワークを最大限利用する必要がある(勝手にアップデートって言った方がいいか？)
これはドメインモデルの観点からすると非常に有意義な機能だが、「普通の開発者」にとっては理解しがたい機能のはず。(EJBやってればわかるんだろうけど)
1次キャッシュはhibernateの必須機能のため原則として無効化することはできないが、ラップすることでどうとでもできる。
で、結論としては開発者がユニットオブワークを理解できるのなら、hibernateを使えば良い。難しいようであればS2DaoやiBatisのようななんちゃってO/Rマッパーを使った方がいい。 >>56
だがそのなんちゃってO/Rマッパーが一番使い易い。
どうせフルO/Rマッパーなんて速度も出ないし、
複雑なことしようとしたかったらSQL書かなくちゃいけないし、
そもそもフルO/Rマッパーなんていらねーんだよ。
そんなに永続化データをオブジェクトで扱いたいなら
オブジェクトDB使えよチンカスカス。 言葉遣いは激しくダメだと思うけど >>57 の意見には賛成。
少数精鋭でやる小さな案件ならぶっちゃけ何やってもいいと思っているけど、
規模が大きくなればなるほど「普通の開発者」の占める割合が大きくなる訳で。
今の低予算かつ短納期なご時世では育成、教育にかける余裕が全然ない。
となると、より理解しやすい方を採用するのは必然じゃないかな。
ついでに、開発が終わった後は運用保守フェーズに入る訳で、「普通の運用保守担当者」が理解しやすいかどうかも大切だよね。 >>57
>だがそのなんちゃってO/Rマッパーが一番使い易い。
>どうせフルO/Rマッパーなんて速度も出ないし、
「フルO/Rマッパー = パフォーマンスダメ」っていう議論はかなり飛躍しすぎだと思う。
これだと、なんちゃってO/Rマッパーを使えばパフォーマンスがでると誤解されかねない。
フルO/Rマッパーを考慮したクラス設計、ER設計にしなかった場合にパフォーマンスが劣化する、ってのが正しい。
で、この手の議論は大抵hibernateやJPAなどを「なんとなく」使って火傷した人が吹聴する場合が多い。
そうなる気持ちは十分わかるので、あまり強く突っ込みたくないけど、技術者ならもうちょっと勉強した方がいいと思う。
■ このスレッドは過去ログ倉庫に格納されています
