ドメインモデル VS トランザクションスクリプト
最近携わったプロジェクトのアーキテクチャは皆、トランザクションスクリプト。
SQLがわんさか書かれた後に、DBの変更が頻繁に行われるので、生産性が著しく下がる。
PofEAAで解説されているドメインモデルでどうして実装しないんだろう？
俺が身近な人に聞いた理由：
１．難解なモデリングをするイメージがあるから（アナリシスパターンのせいか？）
２．どうすれば実現できるかわからないから（アーキテクチャが複雑になるから？）
３．業務アプリにドメインモデルは向かないから（イベントドリブンではないから？）
４．Hibernate(EJB3)が重厚すぎてトラブルが起きたときに怖いから（フレームワークのノウハウがないから？）
５．画面毎に実装させないと作れないから（開発者がへぼいから？）
俺はHibernateを使わずにDAO＋リッチなORマッピング処理を自動生成する方法
（Ruby On RailsのActiveRecordみたいなかんじかな）で開発するのが好きで、
それを使ったプロジェクトでは実際に、生産性も保守性も高いと思うんだけど。。
どう思う？ >>90
複雑なキャッシュ(依存関係や階層ね)をモデリングしたい、って感じ。
DataStore 頻繁に叩いたり、デカいFramework起動すると
金かかるんだよね。
開発期間も短かくしたいから、うすいドメインモデルでいい。
ORMとストアドの適材適所について雑談はっとく
ttp://togetter.com/li/10063 >>122
エンジニアライフの記事をいくつか読んだけど生島勘富がひどすぎるｗ
社長で実名なのに読解力無さすぎ、カス・クズって言い過ぎｗ
77と被るけど結論は真逆なのがまた面白い
もしもまだ居たら77の感想が聞いてみたい >>77さん勘違いしてますね。
オブジェクトを永続化するときにオブジェクトのまま扱えるのか、
パーシスタント層を意識してデータに変換してあげなきゃいけないのか、
がフルスタックORMとなんちゃってORMの違いなのに、ドメインモデルか
トランザクションスクリプトかは関係ない。
自システムでDBを扱わず永続化を外部システムに丸投げしてHibernateもiBatisも
使わない場合だって、ドメインモデルでもトランザクションスクリプトでもどっちでも書ける。
これにS2Daoをなんちゃってと言われたことを面白くないと思った人が
過剰反応してこじれてしまったのだろうか。
>>122に関連して
SQLにドメインロジック入れるのは2層時代の作り方だよ。パフォーマンスは
一番出るけど拡張性、メンテナンス性を考慮しつつコードを自動生成して
巨大なシステムを短納期で作って、ボトルネックになるところだけ改善するっていう
今のやり方とは合わない。
データベースアクセス部分と、モデルを分離したほうがいいと思う。 >オブジェクトを永続化するときにオブジェクトのまま扱えるのか、
>パーシスタント層を意識してデータに変換してあげなきゃいけないのか、
>がフルスタックORMとなんちゃってORMの違いなのに、ドメインモデルか
なんだこのオレオレ定義ｗ
しかもデータに変換って… 新着チェックしてるけど
エンタープライズ系は、もう過去の世界の話なので、どうでも良い気がする
今は、クラウド系のアーキテクチャデザインの方が知りたいわ
エンタープライズの意味もドメインモデルの意味も何も分かってないんだろうな
的はずれにも程がある >>1の
>５．画面毎に実装させないと作れないから（開発者がへぼいから？）
これ多い。画面ごとにdao作ってってパターン。
ン億かけた某社のWebシステムもこれだった。
で、顧客から「今度小さいシステムを別で用意するんだけど、
こないだの情報と組み合わせてちょろっと出したい」と言われた時に
画面特有ロジックと密結合過ぎて切り出せない。
1画面の情報 = 1テーブル。無理。yobi6とかいうカラムまである。
仕方ないから完全別でシコシコ作る。当然one fact, many placesになる。
それで解決策を探してたのがドメインモデルを知るきっかけだった。
まだ勉強中だけど。
ちなみに画面ごとに作る理由を聞いてみたら、
画面数と帳票数からクラス数とかが分かるから、
見積もりがしやすいって意見だった。
>>131
「こういう場合に」とかの具体例がないとなんともいえないのでは。 俺はトランザクションスクリプトのほうが
粗結合になりシンプルで好きです。
ドメインモデルはLLライクな気がする >>133
> ドメインモデルはLLライクな気がする
何か誤解してるな
LL≒スクリプト言語
スクリプトと付く意味を考えたらこの結論は出ない >>134
ドメインモデルは大クラス主義だという意味さ ＞LL
俺の考えとしてはエンティティは単純なVOであるべき。
ドメインオブジェクトがFacade的な役割に過ぎないならいいけど
エンティティと一体化した実装だとすれば肥大化しすぎる >>135
ドメインモデルだから大クラス主義ということはないし（どちらかと言えばむしろ小クラス）、
大クラス主義はあくまで特定言語のライブラリの思想であって、LLとは直接の関係はない。
VO（Value Object）の意味も誤解している。（PoEAAを参照）
> ドメインオブジェクトがFacade的な役割に過ぎないならいいけど
これではドメインモデルとはいえない。
> エンティティと一体化した実装だとすれば肥大化しすぎる
適切に実装できれば、個々のクラスが肥大化することはない。システム全体で見てもトラン
ザクションスクリプトの方がコードの重複が発生しやすく、肥大化のリスクが高い。 全てが頭の中に入るような小規模ならDDDでもいいかな
DIとDDD相性悪いのはどうなんだろ >>137
全くの逆で、大規模・複雑な問題こそドメインモデルが適している。
また、DIとの相性が悪いということもない。むしろドメインモデルにこそ必要。
あまりにひどいから釣りかとも思ったけど、「DIコンテナとドメインモデルの相性の悪さ」
というブログ記事を読んで納得した。たぶんこの記事を読んだんだろう。
> ドメインモデルは、非常に単純化しすぎた言い方をすれば、トランザクションスクリプトの
> EntityとLogicを1クラスにまとめたようなプログラミングモデルになる。
こんな馬鹿な設計はないしドメインモデルでも何でもない。この通りに実装したら確かに
>>135,137の通りになる。
>>11で酷評されてるが「ドメイン駆動」は良書だから読むことを薦めるよ。 保守：
コードの重複を減らして変更に強くする
可読性の低い複雑なアーキテクチャ
設計：
RDBのデータ設計、パフォーマンスに難あり
開発工程が、人数増やしても効果出にくい設計フェーズに集中する
実装：
コードの量が少ない、人件費少ない。
OOP的なコード書くの嫌いor書けない人多い。 >>138 を受けてドメイン駆動読んでみたよ。
読後感としては、ドメインモデルってそこまでお堅いもんでもないのかな、と。
著者も著者の友人も、ドメインモデルをそれぞれ解釈している。
特に.NET界隈の事情の影響が非常に大きいのではないかと感じた。
MicrosoftのTier分割思想が垣間見得た。
このスレでドメインモデルを知った俺としては、ここの人の方がよっぽど純粋主義に見える。
「ドメイン駆動」がドメインモデルの体現だというのはにわかに首肯しかねるけど、
実践部分に特化した部分では意義があると感じた。
「そういう解釈もあるのか」という部分も強く感じたので、もう一度PoEAAを読み直す予定。 PofEAAの読書会ってないのかなと思ったら、昔あったのか。
それにしても2005年時点で「もう古い」という意見が多々。
確かにドメインモデルを使わない案件でもRow Data Gatewayはもう一般的。
O/Rマッパーも一般的か。クラス構造とテーブル構造が一致している場合での、
効率化目的で使われていることがほとんどではあるように思うけど。
この読書会に参加した方は、今どういった方面に向かっているのだろうか。
何世代も遅れている上に、まだまだ理解の足りない自分に若干の嫌気。 >>142
ドメインモデル関連はPoEAAよりも>>40のほうが参考になると思う
ドメイン駆動を読んだら理解できるようになってるはず おまいらQcon行きますか？Eric Evance来るよ。 Row Data GatewayよりO/Rマッパーが主流になるながれでしょ Row Data GatewayにマップするためにO/Rマッパーを使う、じゃないの？
O/RマッパーのないRow Data Gatewayとか死ぬほど大変そうなんだけど。 このスレ見てるやつは、とうに知っているだろうけど、DDDの邦訳
＞ttp://www.seshop.com/product/detail/13087/
＞
＞エリック・エヴァンスのドメイン駆動設計
「エリック・エヴァンスのドメイン駆動設計 」ｷﾀｰｰｰｰｰｰ！
原書も持ってるけど、理解が怪しい部分もあるし、なんだかんだで邦訳はありがたい。
今からざっと目を通すけど、糞翻訳でないことを祈るのみだわ。 翔泳社特典でTシャツももらったけど、どうしようかなこれ。Qconでサインでももらうかな。
いやー待っただけあって、なんか興奮するわ。酒も入ってるけど。
おまえらもモチベーション上がってくるよな？な？ ちょっとみなさんに質問です。
>>8 で書かれている Eric Evans の Domain Driven Design の日本語訳が、
>>148 の 翔泳社の本ですよね。
>12 や >>138 で書かれている「ドメイン駆動」というのは、
http://www.seshop.com/product/detail/8906/
の本のことでしょうか? >>60
> 「O/Rマッパー = オブジェクトクエリでCRUDできる」が正しい。
「出来る」だってｗ
hibernate案件で
副問い合わせした後でgroup byしたものをjoinする必要があったが
ヘンテコなクエリで悩まされたわ
あんな独自の馬鹿馬鹿しいクエリは二度と使いたくないね
やっぱりSQLで問い合わせるのが一番だ
> JPA、hibernate、EntityBeanは1次キャッシュの機能がある
> (つまり、UinitOfWorkをアーキテクチャの原則としている)
>
> S2Dao、iBatisにはそういう機能はない
>
> この違いを表現するのに"なんちゃってO/Rマッパー"と言っているだけ。
> ほかに良い表現方法があればそれを使うけど、特にないのでそう言っている。
遅レスだがｗ
なんだコイツ？
「一時キャッシュがあるから高機能」とか
馬鹿か？
どんだけ永続化マンセー野郎なんだ
そのキャッシュの間に、本番DBの値が変更したらどうなるか？
更新の時に不具合が出る場合もあることに頭が回らんのかねｗ
>>156
> そのキャッシュの間に、本番DBの値が変更したらどうなるか？
心配しなくてもそれなりのODBはキャッシュコヒーレンシープロトコルをもってる
>>157
Oracleで言うと、読み取り一貫性の機能を言いたいんだろうが
勘違いしてるな
Aが画面で編集してる間に
Bが更新処理を完了してる、というケースを考えてみろ
Aがイザ更新をしようとすれば、すでにDBの値は変更されてしまっている
そのまま更新しようとすると制約などがあればエラーになるケースもある DDDとHibernateとか糞実装系の話を一緒にするのは止めて欲しいな〜。 DDDの話=Hibernateの話と勘違いした厨がわき、それに対するアンチがわき、
モデル層の話はほとんど行われない、っといういつもの光景か。 ＪＰＡ信者＝Hibernate信者
これも否定できない事実だ 転職時の注意事項。
下記の条件が全て当てはまる会社にご注意下さい。
・IT系 in Tokyo
・転職会議で2.5点
・転職会議の「その他>2ch情報」の欄で過去の労基2chスレが表示される 誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
0CDL40HJOV 
