ドメインモデル VS トランザクションスクリプト
■ このスレッドは過去ログ倉庫に格納されています
>>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できる」が正しい。
「出来る」だってw
hibernate案件で
副問い合わせした後でgroup byしたものをjoinする必要があったが
ヘンテコなクエリで悩まされたわ
あんな独自の馬鹿馬鹿しいクエリは二度と使いたくないね
やっぱりSQLで問い合わせるのが一番だ
> JPA、hibernate、EntityBeanは1次キャッシュの機能がある
> (つまり、UinitOfWorkをアーキテクチャの原則としている)
>
> S2Dao、iBatisにはそういう機能はない
>
> この違いを表現するのに"なんちゃってO/Rマッパー"と言っているだけ。
> ほかに良い表現方法があればそれを使うけど、特にないのでそう言っている。
遅レスだがw
なんだコイツ?
「一時キャッシュがあるから高機能」とか
馬鹿か?
どんだけ永続化マンセー野郎なんだ
そのキャッシュの間に、本番DBの値が変更したらどうなるか?
更新の時に不具合が出る場合もあることに頭が回らんのかねw
>>156
> そのキャッシュの間に、本番DBの値が変更したらどうなるか?
心配しなくてもそれなりのODBはキャッシュコヒーレンシープロトコルをもってる
>>157
Oracleで言うと、読み取り一貫性の機能を言いたいんだろうが
勘違いしてるな
Aが画面で編集してる間に
Bが更新処理を完了してる、というケースを考えてみろ
Aがイザ更新をしようとすれば、すでにDBの値は変更されてしまっている
そのまま更新しようとすると制約などがあればエラーになるケースもある DDDとHibernateとか糞実装系の話を一緒にするのは止めて欲しいな〜。 DDDの話=Hibernateの話と勘違いした厨がわき、それに対するアンチがわき、
モデル層の話はほとんど行われない、っといういつもの光景か。 JPA信者=Hibernate信者
これも否定できない事実だ 転職時の注意事項。
下記の条件が全て当てはまる会社にご注意下さい。
・IT系 in Tokyo
・転職会議で2.5点
・転職会議の「その他>2ch情報」の欄で過去の労基2chスレが表示される 誰でも簡単にネットで稼げる方法など
参考までに、
⇒ 『半藤のブブイウイウレレ』 というサイトで見ることができます。
グーグル検索⇒『半藤のブブイウイウレレ』
0CDL40HJOV ■ このスレッドは過去ログ倉庫に格納されています