ドメインモデル VS トランザクションスクリプト
■ このスレッドは過去ログ倉庫に格納されています
>>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などを「なんとなく」使って火傷した人が吹聴する場合が多い。
そうなる気持ちは十分わかるので、あまり強く突っ込みたくないけど、技術者ならもうちょっと勉強した方がいいと思う。
>>57
>複雑なことしようとしたかったらSQL書かなくちゃいけないし、
正確に言えばO/Rマッパーは原則としてSQLを書かない。
オブジェクトグラフを操作するクエリを書く。
一見似ているので誤解されやすいけど、根本的に違うものなので注意した方がいい。
なお、「O/Rマッパー = クエリ書かなくてよい」なんてのはスーツが言ってるペテン。
「O/Rマッパー = オブジェクトクエリでCRUDできる」が正しい。
>そもそもフルO/Rマッパーなんていらねーんだよ。
ドメインがリッチなモデルで、かつ、開発者にO/Rマッパー&モデリング&ER設計の
熟練者がいる場合は採用すればいいと思う。ソースコード記述量、美しさ(DDDとしてのね)、移植性
は明らかになんちゃってO/Rマッパーよりも高い。
そうでなければS2Daoとか使えばいいと思う。
だから「いらねー」なんてのは極論すぎ。
>そんなに永続化データをオブジェクトで扱いたいなら
>オブジェクトDB使えよチンカスカス。
プログラムではオブジェクトとして扱うのだから、永続化や抽出処理もオブジェクトとして扱いたい
というのがO/Rマッパーの本質。
なんで、O/Rマッパーは永続化先のストアはファイルでもKVSでもDBでもオブジェクトDBでもなんでもよい。
なんでもマップできますというのがO/Rマッパーの特徴。
オブジェクトDB使えっての少々議論不足。 ＞「フルO/Rマッパー = パフォーマンスダメ」っていう議論はかなり飛躍しすぎだと思う。
んなこたーない。
hibernateが吐き出したSQL見ると酷いぞー
AとBというテーブルをJOINして一覧取得したいだけなのに
AとBをJOINしたものをさらに副問い合わせでくるんでSELECTしてた。
設計がどうたらのレベルじゃねぇの。
＞正確に言えばO/Rマッパーは原則としてSQLを書かない。
＞オブジェクトグラフを操作するクエリを書く。
＞一見似ているので誤解されやすいけど、根本的に違うものなので注意した方がいい。
＞プログラムではオブジェクトとして扱うのだから、永続化や抽出処理もオブジェクトとして扱いたい
＞というのがO/Rマッパーの本質。
だから無理にRDB使わなくていいじゃん。
＞なんで、O/Rマッパーは永続化先のストアはファイルでもKVSでもDBでもオブジェクトDBでもなんでもよい。
＞なんでもマップできますというのがO/Rマッパーの特徴。
DAOパターンでそれできてますけど。
>>61
>んなこたーない。
>hibernateが吐き出したSQL見ると酷いぞー
>AとBというテーブルをJOINして一覧取得したいだけなのに
>AとBをJOINしたものをさらに副問い合わせでくるんでSELECTしてた。
>設計がどうたらのレベルじゃねぇの。
いや、だから、なんでそういうSQLになるのかを考慮して設計する必要が
あると言ってるわけです。（ただ、この例であれば
フェッチ方法を変えるだけで解決しそうだけど）
なんで、そういう考慮をしたくないのであれば、hibernateを使わず、S2Daoを
使えばよいとも言ってます。
60でも書いたけど、hibernateを真に使いこなすには
「O/Rマッパー&モデリング&ER設計」の熟練者が必要。 >だから無理にRDB使わなくていいじゃつん。
極論すぎ…。
例えば、DBとKVSをハイブリッドで使用するケースは結構あると思うけど、
オブジェクトクエリによってこれらリソースの差異を吸収するわけです。
>DAOパターンでそれできてますけど。
DAOパターンではDAOクラスによってリソースの差異を吸収するけど、
ここではオブジェクトクエによってリソースの差異を吸収します。
だから、レイヤーのポイントがちょっと違う。
DBとKVSをハイブリッドにした場合、
DAOパターンではDB用のDAOとKVS用のDAOを作る必要があるけど、
O/Rマッパーではオブジェクトクエリがそれを代用してくれる。 ＞60でも書いたけど、hibernateを真に使いこなすには
＞「O/Rマッパー&モデリング&ER設計」の熟練者が必要。
O/Rマッパーの意義の根幹を覆す発言だな。
そんなに苦労しなきゃいけないのなら使う必要ないよ。 >>64
根幹を覆す発言ではなくて、O/Rマッパーを使いこなすにはそういうスキルが必要と
オフィシャルなドキュメントにも書いてある。
つまり、これらは前提。
O/Rマッパーを使う意義については60で書いたとおり。
この意義がどうしても納得でいのならhibernateを使わなければいいだけのこと。
問題なのはこういう前提をしらずに「なんとなく」使って火傷して「使えねえ」と
非難する人間。技術者なら実装レベルだけでなく、設計レベル、思想レベルでアーキテクチャを
評価したほうがいいと思う。 >>56
O/Rマッパーとは"オブジェクトとDBのデータを相互に変換するツール"と認識しているが
なんでS2DaoやiBatisがなんちゃってO/Rマッパーになるのか分からない
十分にO/Rマッパーとしての機能を有しているし、Hibernateとは異なる思想に基づいて
設計されているだけで、それぞれ長所と短所があり、単純にHibernateが理解できるか
どうかだけで使い分けるようなものでもないはず
>>60
>なんで、O/Rマッパーは永続化先のストアはファイルでもKVSでもDBでもオブジェクトDBでもなんでもよい。
>なんでもマップできますというのがO/Rマッパーの特徴。
上に書いたようにどうもO/Rマッパーの認識に差があるように思えるが、それはいいとして
これは本来こうあるべきだという理想の話をしているのか？
Hibernate等なら、さも簡単にできるかのように書かれているが、少なくとも現時点では
実現できていないはず。当然、移植性も特段高くはない
移植性を高めるには>>61のいうようにDAOを使い分けるのが現実的な対処法だろう
これに対し、"レイヤーのポイントが違う"という指摘はあまり意味が無い
それから何かと"差異を吸収"というけど、モデリングやER設計に精通してなくてはならず
場合によって互いに大きく影響を与えなければ使えないというのでは、一体何を吸収して
いるのか分からない。本来は単なるツールであるのに、その美しさや理想のために実装を
犠牲にするのなら本末転倒だろう
HibernateやJPAが有用であることは否定しないが、全体的に現実の問題を無視して
過大評価になりすぎている FWって本来は実装を簡単にさせるってのが役割なはずなのに
O/Rマッパー、モデリング、ER設計の熟練者が必要でとかって
敷居が高くなってたら本末転倒過ぎだろｗ
しかもSQL直接書かないのが前提だから速度出ないしｗ
S2DaoとiBatis意外考えられんわ。 >>66
>O/Rマッパーとは"オブジェクトとDBのデータを相互に変換するツール"と認識しているが
>なんでS2DaoやiBatisがなんちゃってO/Rマッパーになるのか分からない
JPA、hibernate、EntityBeanは1次キャッシュの機能がある
(つまり、UinitOfWorkをアーキテクチャの原則としている)
S2Dao、iBatisにはそういう機能はない
この違いを表現するのに"なんちゃってO/Rマッパー"と言っているだけ。
ほかに良い表現方法があればそれを使うけど、特にないのでそう言っている。
で、使い分けについては、細かい機能の差異はともかくとして、
"1次キャッシュ"を採用する・しないがアーキテクチャレベルでの最も大きなポイントになる。
だからそこを議論の中心にするのが当然のことでしょう。
その代表格としてhibernateをあげているだけのこと。
>上に書いたようにどうもO/Rマッパーの認識に差があるように思えるが、それはいいとして
>これは本来こうあるべきだという理想の話をしているのか？
アーキテクチャを構築するとき、実装はともかくとして、思想レベルでどうしたいかまず考える。
で、オブジェクトを中心としたアーキテクチャにしたい場合にhibernateなどのO/Rマッパーの採用を考える。
で、数々の指摘の通り、hibernateを使いこなすにはかなりのスキルが必要。
だけど、がんばれば思想に近いものを実装レベルで表現できる→ゆえにhibenrateを使う。
というのが、hibenrateを使う人の思考回路でしょう。 >>66
簡単に"実装できる"ということは大事だけど、それ以上にアーキテクチャには一本筋の通った思想が必要だということ。
だから一番嫌いなのが、ERを中心としたアーキテクチャにしているのにhibernateを使用すること。
また、逆にオブジェクトを中心としたアークテクチャなのにS2DaoやiBatisを使用すること。
そういう意味でここでは思想に関しての比重を重めに話している。
だから、思想なんてともかく、とにかく簡単にやりたい人はS2Daoを使えばよいと言っている。
>Hibernate等なら、さも簡単にできるかのように書かれているが、少なくとも現時点では
>実現できていないはず。当然、移植性も特段高くはない
実現できていないはず、と言われても困るわけで、何をどう実現できていないのか書いて欲しい。
過去の経験上、MySQL、PostgreSQL、Oracleでは同一のコードで動作したし、
同時に、2次キャッシュとしてKVSを利用しても問題なく動作してる。
>移植性を高めるには>>61のいうようにDAOを使い分けるのが現実的な対処法だろう
>これに対し、"レイヤーのポイントが違う"という指摘はあまり意味が無い
hibernateはオブジェクトを中心としたアーキテクチャのため、リソースの違いをオブジェクトクエリで吸収している。
というのがここでの言いたいこと。
それをDaoパターンでできます。と言われれば、もちろんその通りなのだが、
質問者が「リソースの違いをオブジェクトクエリで吸収している」という大事なアーキテクチャのポイントを理解して
いなかったぽいから補足しただけのこと。
>本来は単なるツールであるのに、その美しさや理想のために実装を
>犠牲にするのなら本末転倒だろう
とはいっても、思想のないアーキテクチャも駄目でしょう？
これはバランスの問題で、アーキテクトがプロジェクト初期の段階でジャッジする事柄でしょう。 >>68
>FWって本来は実装を簡単にさせるってのが役割なはずなのに
>O/Rマッパー、モデリング、ER設計の熟練者が必要でとかって
>敷居が高くなってたら本末転倒過ぎだろｗ
これはアーキテクトの仕事。
たぶん。あなたの仕事じゃないよ。
メンバーはドメインを作ることはないだろうから大丈夫。
>しかもSQL直接書かないのが前提だから速度出ないしｗ
もうちょっと過去ログを見るなり、なんなりした方がいいと思う。
技術者として本気でそう思ってるのなら、さすがにキツイと思う。
煽りで書いているのなら反応した自分を恥じるけど。
>S2DaoとiBatis意外考えられんわ。
そういう人はS2Daoを使えばいいと思うよ。
なにも使うななんて一言もいっていない。
自分もドメインがシンプルなプロジェクトではiBatis使う場合があるよ。 >>67
>ドメインモデルと ORM って無関係だよね
机上レベルだと無関係。
だけど、それを実装レベルに落とし込んだとき、ちょっと関係してくる。
というもの。 >>FWって本来は実装を簡単にさせるってのが役割なはずなのに
>>O/Rマッパー、モデリング、ER設計の熟練者が必要でとかって
>>敷居が高くなってたら本末転倒過ぎだろｗ
>
>これはアーキテクトの仕事。
>たぶん。あなたの仕事じゃないよ。
>メンバーはドメインを作ることはないだろうから大丈夫。
いやいや、Hibernateなんかは実装もかなり面倒だったぞ。
副問合せどうすればいいのよみたいな。
ま、普及することはないべ。 >>73
副問い合わせする方法なんて、公式のリファレンスを検索すれば5分でわかると思うよ。
調べるのが嫌とか、新しく覚えるのが嫌というのであれば仕方ないけど。
普及はともかくとして、せっかくなんで書籍の一冊くらいはちゃんと読んだ方が
技術者としての懐が絶対に広くなると思うよ。
それすらを求めないのなら、そもそも議論に参加しない方がいいと思う。 >>69
>JPA、hibernate、EntityBeanは1次キャッシュの機能がある
>S2Dao、iBatisにはそういう機能はない
>この違いを表現するのに"なんちゃってO/Rマッパー"と言っているだけ。
それはおかしいでしょ
Hibernate等がO/Rマッパー＋αの機能があること表現するために、O/Rマッパーとしての
機能を十分に備えた他のものを"なんちゃって"と表現する人はいない
>アーキテクチャを構築するとき、実装はともかくとして、思想レベルでどうしたいかまず考える。
思想を語るのは大いに結構だが、他の人が現実の問題の話をしているのだから現実から
離れた話をするときは何らかの前置きはするべき
>実現できていないはず、と言われても困るわけで、何をどう実現できていないのか書いて欲しい。
>過去の経験上、MySQL、PostgreSQL、Oracleでは同一のコードで動作したし、
>同時に、2次キャッシュとしてKVSを利用しても問題なく動作してる。
RDBに関しては動作して当然でしょう
KVSに関しては>>60の文脈からすると、メインの永続化先としてRDBと何ら変わらずに
使えなければおかしいが、それはできていないということ
それから、この例だけでは>>60であげていた移植性の明らかな優位も認められない
>それをDaoパターンでできます。と言われれば、もちろんその通りなのだが、
>質問者が「リソースの違いをオブジェクトクエリで吸収している」という大事なアーキテクチャのポイントを理解して
>いなかったぽいから補足しただけのこと。
上に書いたように>>61は明らかに現実の話をしている
理解していなかったのではなく、レイヤーのポイントの違いなど問題にしていないだけ
あとついでに、ちょいちょい出てくる人を見下した表現は気を付けた方がいいよ
読んでても気分よくないし、2chといえど今は真面目に話をしてるわけだから >> 75
>それはおかしいでしょ
>Hibernate等がO/Rマッパー＋αの機能があること表現するために、O/Rマッパーとしての
>機能を十分に備えた他のものを"なんちゃって"と表現する人はいない
思慮の足りない名称ですいません。
正直、名称はどうでもいいので、何か適切な言い方を提案してください。
ただ、古いEJBをやってた人間からすると、O/Rマッピングには主に二つの機能があって、
グラフ構造 <-> 表構造のマッピング(静的な構造のマッピング)
オブジェクトインスタンス <=> レコードの内容(ステートのマッピング)
があるので、S2Daoなんかはどうしてもなんちゃってに見えます。
で、それが悪いなんて一言も言ってないので安心してください。
>思想を語るのは大いに結構だが、他の人が現実の問題の話をしているのだから現実から
>離れた話をするときは何らかの前置きはするべき
>>56で
「真にドメインドリブンアーキテクチャを追求した場合、1次キャッシュによるユニットオブワークを最大限利用する必要がある(勝手にアップデートって言った方がいいか？)」
と書いたつもりだったんですが、もう少し具体的に書けばよかったですね。
>>75
>RDBに関しては動作して当然でしょう
>KVSに関しては>>60の文脈からすると、メインの永続化先としてRDBと何ら変わらずに
>使えなければおかしいが、それはできていないということ
永続化先にファイルは確かに言い過ぎで、そもそもマップする必要がないですね。
ただ、DB<->KVSについてはあります。この場合、現実的な解としては
メインの永続化先としてDBを、2次キャッシュとしてKVSを採用した方が
ワークしやすい(ノウハウがある)のでそうしてるだけです。
>それから、この例だけでは>>60であげていた移植性の明らかな優位も認められない
75のいう移植性とは何でしょうか？
私がここでいう移植性とは「リソースごとにコードを作成する必要がない」といものです。
もう少し詳しく言うと「コードを作成する必要がない」のはサービス層の話で、
core層(ここではhibernate)などでは死ぬほどがんばります。
DAOパターンは特殊なコーディングをしない限り、原則としてリソースごとにコードを作成する必要があるでしょう。
>あとついでに、ちょいちょい出てくる人を見下した表現は気を付けた方がいいよ
>読んでても気分よくないし、2chといえど今は真面目に話をしてるわけだから
真面目に話している人には真面目に回答しているつもりです。
>>61、>>64、>>68、>>73なんて、若干煽りも含んだあまりに低レベルな書き込みなので
それ相応の回答したまでです。 >>75
なんていうか、このスレはドメインモデル vs トランザクションスクリプトなわけで、
必然的に「ドメインモデル派 = hibernate」「トランザクションスクリプト派 = hibernate以外」という構図が自分にはある。
ここでhibernate嫌だと言ってる人はトランザクションスクリプト派ってこと？ Hibernateを否定しているのは>>68だけな気ガス。
ドメインモデルの何たるかを知らんヘボ外野だけど、
煽りに対して、同レベルの煽りや極論で返すのはダメだってばっちゃが言ってた。 私はドメインモデルでシステムを何回か作ったことがあるので、
その時の構成を書きますね。
レイヤーは以下の通りにわけます。
インテグレーション層(Dao、Mao、Wao)
ドメイン層
サービス層
アプリケーション層(コントローラー、アクション)
プレゼンテーション層
各層の説明は不要でしょう。
次に振る舞いの持たせ方ですが、
(1)まずはアプリケーション層に書きます。
(2)アプリケーション層で重複・相互参照があるとサービス層に委譲します。
(3)サービス層で重複・相互参照するとドメイン層に委譲します。
(4)ドメイン層で重複するとユーティリティクラスに集約します。
といった感じで、いきなりドメインモデルを考えるのではなく、リファクタリングにより
結果的にドメインモデルができます、という方式を採用します。
(もちろん設計レベルで明らかにドメインに関するロジックのものはドメインに持たせますが)
これらをプロトタイピングの時にやってしまえば、ある程度実践的なドメインモデルができます。
特にシステム化する業務をよく知らない場合はこの方法が一番無難だと思います。
逆に詳しい業務をシステム化する場合はこういう洗練作業を飛ばして、過去のノウハウをもとに
ドメインに振る舞いをガンガンくっつければいいと思います。 次に、コーディングレベルの話として、
アプリケーション層にはビジネスロジックおよびビジネスロジックに関する分岐は一切かかないこと。
ただし、制御に関する分岐は書いていい。
サービス層はドメインのビルド(DBから必要なドメインをとってきたり、
ドメインの振る舞いを呼び出したり)をメインとする。
ビジネスロジックを書いてもいいが、それは緊急手段。
これらを遵守すると、大抵以下のようなコードになる。
注文を登録もしくは更新するユースケース
# アプリケーション層
public View hogeAtcion(Model model) {
// 登録、更新で分岐処理
if (model.isNew()) {
hogeService.persist(model);
} else {
hogeService.merge(model);
}
return new View(model);
}
# サービス層
public void HogeService {
// 登録用のサービス
// 他のエンティティをくっつけて、計算して永続化する
publc void persist(Model model) {
model.addOtherEntity(fooService.getOtherEntity(model.key));
model.calculate();
modelDao.persist(model);
}
// 更新用のサービス
// モデルをマネージドにし、関連エンティティを再取得し、計算して更新する
publc void merge(Model model) {
modelDao.merge(model);
model.refreshOtherEntity();
model.calculate();
}
} >>76,77,78
>があるので、S2Daoなんかはどうしてもなんちゃってに見えます。
>で、それが悪いなんて一言も言ってないので安心してください。
意味不明すぎて全く安心できない
>私がここでいう移植性とは「リソースごとにコードを作成する必要がない」といものです。
>もう少し詳しく言うと「コードを作成する必要がない」のはサービス層の話で、
>core層(ここではhibernate)などでは死ぬほどがんばります。
ここでも何を言っているのか分からない
そもそも、説明として"死ぬほどがんばります"は酷過ぎる
何をどのように頑張るのか？
"死ぬほど"なのに移植性が高いことの説明になっているのか？
一般的な"移植性"の意味についてはwikipediaで
http://ja.wikipedia.org/wiki/%E7%A7%BB%E6%A4%8D%E6%80%A7
>ここでhibernate嫌だと言ってる人はトランザクションスクリプト派ってこと？
>>79も書いているが、質問する相手を間違えていないか？
それに、トランザクションスクリプト派だと答えたら、それだけで見下されそう
>真面目に話している人には真面目に回答しているつもりです。
>>>61、>>64、>>68、>>73なんて、若干煽りも含んだあまりに低レベルな書き込みなので
>それ相応の回答したまでです。
はじまりは>>56からで、一貫して同じ印象を持っている
それと、低レベルなとこまでわざわざ合わせてくれなくていいから RDBは表構造なんだから無理にオブジェクトで扱おうとすることに
そもそも無理がある。
だからインピーダンスミスマッチなんてものが発生する。
希望としてはもうHibernateに代表されるフルO/Rマッパーなんてものは
無くしてしまって、RDB使う場合はS2Dao、iBatis系のO/Rマッパーを使う。
どうしても永続化データをオブジェクトで扱いたい場合は
オブジェクトDBを使うという風にならんかね。 >>84
>意味不明すぎて全く安心できない
最近のO/Rマッパの定義はともかく、初期のJavaでのO/RマッパはEntityBeanでその定義を正とすると
S2Daoは機能が足りてない(省かれている)と言ってるだけですよ。
ほんとそれだけです。
で、機能が足りないから悪いなんて言ってないし、見下したりもしてないですよ。ほんと。
なんでこんなどうでもいい所を気にするか正直わけわからんのですが。
>ここでも何を言っているのか分からない
>そもそも、説明として"死ぬほどがんばります"は酷過ぎる
>何をどのように頑張るのか？
>"死ぬほど"なのに移植性が高いことの説明になっているのか？
システムには大きく分けると「業務に依存したコード」「業務に非依存のコード」ってありますよね。
Daoは大抵の場合「業務に依存したコード」になりますよね。
hibernateは「業務に非依存のコード」になりますよね。
ここでDaoパターンを使うと「業務に依存したコード」に外部リソースへの依存関係が混入します。
対してhibernateを拡張すれば「業務に非依存のコード」を改修するので、「業務に依存したコード」はポータブルです。
ということを言いたい訳です。
この説明でも納得してもらえないでしょうか？ >それに、トランザクションスクリプト派だと答えたら、それだけで見下されそう
先に書きましたが、
Hibernateを使ってトランザクションスクリプトにする人はかなり軽蔑します。
S2Daoを使ってドメインモデルにする人も軽蔑します。
というのであって、トランザクションスクリプトを軽蔑なんてしてないですよ。
自分も駆け出しの頃はガリガリのトランザクションスクリプトでした。
ただ、JavaはOO言語なわけだから、インヘリタンス、ポリモーフィズム、カプセル化でシステムを構築したいと思って
ドメインモデルに走った訳です。(その背景にはC時代の構造化設計で限界を感じたこともあります)
>はじまりは>>56からで、一貫して同じ印象を持っている
>それと、低レベルなとこまでわざわざ合わせてくれなくていいから
それはすいません。
ただ、個人的にドメインモデルって言ってるのにhibernateをイマイチよくわかってないっぽい輩がいるので、
気分的にはうんざりした感じなってます。
冗談抜きに、普通ドメインモデルでシステムを構築したいって言ったら、1次キャッシュありのO/Rマッパー使うでしょ？
使わないって言ってる人はいったいどういうアーキテクチャにするつもりなんだろ、と思ってます。
そこを説明してくれたら結構うれしいかもしれません。 話が硬すぎるんだよねー
LL言語で使いたいだけなんだけど
>>83
仕事だと口よりもコードで説明するタイプなので、ある意味楽ですよ。
私に聞いてもらえばコードで答えを返しますから。
そのコードが気に食わなければ修正してもらえばいいので。
そういう意味で、この掲示板では言葉で言い過ぎたので、
>>82でコードを書いたわけですが、これを見て何か思う所があったらぜひ突っ込んでください。
特に↓あたりなんて、1次キャッシュありだからこそできる技なんで、こういうスタンスでコードを書いてる人は
ぜひ意見を欲しい所。
modelDao.merge(model);
model.refreshOtherEntity();
model.calculate(); >>88
LLでドメインモデルを作りたいときってどういうシチュエーションなんでしょう。
つまり、「LLで複雑な業務をモデリングする」ということになるわけですが、
そういうシステムってどんなのなんでしょうか。
この辺はあまり経験がないのでモチベーションを含めて説明してくれるとハッピーです。
あ、ちなみに、89は自分です。 >>86,87
>ほんとそれだけです。
>で、機能が足りないから悪いなんて言ってないし、見下したりもしてないですよ。ほんと。
>なんでこんなどうでもいい所を気にするか正直わけわからんのですが。
どうしても分からないんだけど、この３行は必要なの？
>>84で意味不明と書いたのも「"なんちゃって"と表現するのはおかしい」という指摘に対し、
「安心してください」と返ってきたことに対して。
こういった無駄で相手を不快にする表現を減らせば、中身のない返信に２レス・３レスを
費やす必要もないんじゃないかな
>ということを言いたい訳です。
>この説明でも納得してもらえないでしょうか？
残念ながら…
でもこれ以上はもう結構
>Hibernateを使ってトランザクションスクリプトにする人はかなり軽蔑します。
>S2Daoを使ってドメインモデルにする人も軽蔑します。
最初は人間的に問題はあるが、おそらく技術力は高く仕事はできるのだろうと想像していたが
>>86のような間抜けな例や、論理性の欠片もない返答を見ると、どうも間違いだったようだ
>使わないって言ってる人はいったいどういうアーキテクチャにするつもりなんだろ、と思ってます。
>そこを説明してくれたら結構うれしいかもしれません。
これに関しては、S2Daoの開発者でもある、ひがやすをさんの考え（シンドメインモデル）を
全面的に指示している
（リッチ）ドメインモデルや、>>87があげたOOの利点を十分に活かしつつ、テストや
保守といった現実の問題にも十分に対応できる柔軟さがある
詳しくは氏のブログを参照
念のため書いておくが、この件について君と議論するつもりはないよ >>91
× >>86のような間抜けな例や、論理性の欠片もない返答を見ると、どうも間違いだったようだ
○ >>82のような間抜けな例や、論理性の欠片もない返答を見ると、どうも間違いだったようだ >>91
ひがさん支持のひとでしたか・・・。
いや、なんとなくそういう気がしてたのですが。
Spring VS Seaserの議論も大抵こんな感じになりますよね。
それはともかく、ひがさんも
http://d.hatena.ne.jp/higayasuo/20080201
の「HibernateとS2DaoとS2JDBCの考え方」で
hibernate = Entity中心
S2Dao、S2JDBC = ER中心
と書いてるので「ER中心だけどドメインモデル」っていわれると、
「なんだそれ？」と思う訳です。新手のセールストークかって？
なにをどうドメインモデルなのかと。
というより、ほんとにドメインモデルでシステム作った事あんのかと思います。
きっとないでしょう。ないからこんな事が言えるわけで。
そういう意味で、91さんとは根本的にポジションが違いますね。
無用な議論ほんとにすいません。 >>92
しかし、Seaserラブな人はどうしてhibernateが嫌いなのだろう。
現実でもネットでもみんな嫌いって言ってる。
springはそこまでじゃないのに。
多分ひがさんがhibernate嫌いだからそれにつられてるんだろうけど、
なんだか主体性のなさを感じる。右向け右みたいな。
比嘉さんの言葉を完全に鵜呑みにするんじゃなくて、
もう少し自分で評価して、自分なりの意見を言えばいいのに。
手を動かして複雑なドメインのものをS2Dao、hibernateでそれぞれ実装して、
それで評価すれば簡単なことなのに、それすらしてない人が多い。
してないのに、hibernateは駄目だ。という。
で、何が駄目なのかと一つ一つ問いただしていくと、
結局シングルテーブルマッピングすら理解していなかったりする。
(これは極端な例だけど、感覚として7割以上の人間は1次キャッシュすらわかってない)。
それで、なぜhibernate、ひいてはドメインモデルのなんたるかを非難できるのかと。
スレ汚してほんとすいません。
ただ、技術者だったらもうちょっと自負をもってアーキテクチャを構築して欲しくて・・・。 >>94
俺俺アーキテクチャが理解できる人なら俺俺アーキテクチャで開発するのがベストだ。
これが俺様の結論。俺俺アーキテクチャは100%理想的で完璧だ。
しかし、俺俺アーキテクチャは「普通の開発者」には理解できない。
理解が難しいようであれば、巷のアーキテクチャのような、
「なんちゃって俺俺アーキテクチャ」を採用するしかない。
俺俺アーキテクチャが何故だめなのか。反論に主体性の無さを感じる。
俺俺アーキテクチャを使ってもいないのに非難する。
非難するやつの7割は、結局、俺俺キャッシュすらわかってない。
技術者だったらもうちょっと自負をもって俺俺アーキテクチャを賛美して欲しい。
>>95
レスありがとう。
ちょっと抽象的な内容なので理解していないところもあるけど。
>俺俺アーキテクチャが理解できる人なら俺俺アーキテクチャで開発するのがベストだ。
>これが俺様の結論。俺俺アーキテクチャは100%理想的で完璧だ。
>>82で示した例って、俺俺なんてほとんどなく、
J2EEの5層モデルをドメインを中心にリファクタしただけなんですよね。
これを見て「ああ、５層モデルを参考にしてるんですね」ってのが模範解答で、
更なるリファクタポイントを提示してくれるのが、うれしい回答。
最近は5層モデルなんてどうでもいいのかなあ・・・。
3層と5層を混同してる人が多すぎだし、なんだかなあと思ったりする。
だから、そういうそもそもの前提がない人に非難されると腹が立ってツイ・・・ >>94
>俺俺アーキテクチャが何故だめなのか。反論に主体性の無さを感じる。
>俺俺アーキテクチャを使ってもいないのに非難する。
>非難するやつの7割は、結局、俺俺キャッシュすらわかってない。
>技術者だったらもうちょっと自負をもって俺俺アーキテクチャを賛美して欲しい。
なんていうか、まず議論する前に自分の背景を提示した方がいいですよね・・。
自分はEJBデザインパターン、J2EEデザインパターン、
エンタープライズアプリケーションアーキテクチャパターン、ソフトウエアアーキテクチャ、インテグレーションパターン
なんかの割とメジャーな書籍でアーキテクチャの何たるかを勉強しました。
(細かい書籍をあげると+20くらいなりますが、まあ内容はだいたい似通ってるので)
なんで、逆に比嘉さんのいうアーキテクチャがあまりに俺俺すぎで(=これらの本で提示されている内容と逸脱してる場合が多い)、
それを採用する人は、もうちょっと勉強してみてそれで判断したら？って思うんですよ。
そういう前提があって比嘉さんの意見に賛同なら全然かまわないんですが、
ほとんどの人はそうじゃないんですよね。それなのになんでみんな強気なんだろうと。
技術者としてそれでいいの？って。そんなにアーキテクチャって簡単なの？ってものすごく疑問に思う訳で・・・。 97=77です。
で、>>94は間違い>>95が正解でした。 >>96
あなたの発言自体が中傷的(変換ﾜﾛｽw)かつ独善的で、
たぶんまわりは全然理解できてないですよ。少なくともROMしてた俺にはわからない。
それをあなたは「技術者としてどうか」みたいに見下して言ってるけど、
まずはあなたの俺俺な部分をきちんと説明してはどうですか。
という事を指摘したつもりなんだけど、>>97の回答を見る限り、
問題の根本が伝わってないように見える。
自分の知っているものなら正しくて、そうでないものは俺俺なように見えてるんでしょ。
スレタイにVSとあるけど、対戦相手はあなたが自己中心的に喚いているように見えるわけです。
あなたの背景の確認として、97=77=59=56=54、という事でいいんだよね?
>>56にあなたが書かれた「結論」というものはひどい内容だと思う。
>>59にも「火病ってる」「相手の技術力が低い」という旨の発言をすでに書かれている。
でも>>57の発言を否定できていないよね。むしろ>>54で肯定してるよね。
都合の悪いことを人格否定で濁していて、肝心の議論がおろそかになっているように見えるよ。
>>57の言葉遣いが悪いのは、>>56がフレームのもとになる発言をしているからだ。
そのあたりを見直した上で、>>54とか>>59あたりの反論内容から具体的に書き直して欲しい。
あなたの発言を見ていると、
「ドメインモデルをRDBで採用するには非正規化したテーブルを沢山作る必要がある」
と言っているように見えて、それはあまりレベルが高いアイデアには見えない。
>>99
レスありがとう。
言葉で説明するのは複雑ですね。
コードだと楽勝なんですが・・・。
>>まずはあなたの俺俺な部分をきちんと説明してはどうですか。
俺俺な部分・・・。
>>97で示した書籍がバックグラウンドで、これらがこの世界の教科書だと思ってます。
で、このスレに書き込む人はこういう書籍を一通り読んだ上で実践してるもんだと思ってます。
アーキテクトなら当然の責務とすら思ってました。
(実際、現実のアーキテクトと名乗る人はほぼ100%は読んでて、ちゃんと理解してる)
Seaserは2年くらい使ってて、比嘉さんのブログは毎日見てたけど、
教科書から離れた内容が多かったのと、Seaserは
diとwebが結合しすぎてエンタープライズシステムには沿わない、
一枚岩すぎる、
サンドボックスが信用ならない、
Seaserとしての全体の思想がなく、開発者が勝手にやってる、
っという理由でspringに移行しました。
これが俺俺な部分なんですかね。
自己紹介みたいになりましたが。
何か外してますか？ >自分の知っているものなら正しくて、そうでないものは俺俺なように見えてるんでしょ。
これは、>>100で書いた通りです。
なんていうか、Seaserの考え方はかなり理解しいるつもりなんですけどね・・・。
もともとSeaser使ってたのと、周りがSeaserマンセーなんで、そのおかげなんですが。
>スレタイにVSとあるけど、対戦相手はあなたが自己中心的に喚いているように見えるわけです。
それはそうかも知れませんね。
>>あなたの背景の確認として、97=77=59=56=54、という事でいいんだよね?
>>56にあなたが書かれた「結論」というものはひどい内容だと思う。
その酷さを議論したい。ぜひリファクタして欲しい。
>>>59にも「火病ってる」「相手の技術力が低い」という旨の発言をすでに書かれている。
>でも>>57の発言を否定できていないよね。むしろ>>54で肯定してるよね。
一つのシステムで最重要なビジネスフローを表す部分をドメインモデルで構築して、
バッチや帳票や他システム連携なんかで使う一時的なテーブルはドメインモデルにしない。
そういうケースについて言ってます。
私が一番言いたい事は「複雑な業務ならドメインモデルを使えばいい」、
そうでなければ「トランザクションスクリプト」を使えばいいです。
で、ドメインモデルでやるんだったらhibernate使うでしょう、ということです。
S2Daoとかあり得ないでしょう(思想が全く異なるFWだから)、と。
>>71でもちょろっと言ってます。まあ言い方が足りないんでしょうね。 >都合の悪いことを人格否定で濁していて、肝心の議論がおろそかになっているように見えるよ。
>>>57の言葉遣いが悪いのは、>>56がフレームのもとになる発言をしているからだ。
>そのあたりを見直した上で、>>54とか>>59あたりの反論内容から具体的に書き直して欲しい。
>>101の最後に書いたのが答えになりません？
何も自分はドメインモデルが最強なんて一言も言ってなくて、ドメインモデルでやるんだったらhibernate使うでしょ、
hibernate使えないんだったらドメインモデルやんないでしょ。
ってスタンスで、それに対して議論したいなあ、と思ってました。
>あなたの発言を見ていると、
>「ドメインモデルをRDBで採用するには非正規化したテーブルを沢山作る必要がある」
>と言っているように見えて、それはあまりレベルが高いアイデアには見えない。
こんなのケースバイケースですよ。
たまたまシングルテーブルマッピングがでたからそう思ったのかもしれませんが。
抽象化するドメインの継承関係、バリューオブジェクト、関連、ユースケース、パフォーマンスを考慮して、
マッピング戦略、フェッチ戦略、キャッシュ戦略を考えます。
で、ここをちゃんとやる為にO/Rマッパー&モデリング&ER設計が必要と言ってます。
まだなんか外してますか？
ちなみに移植性うんぬんは本筋から離れるのでなかったことにしてください。
(個人的には結構どうでもいいので)
実際オフ会とかでコードをもとに話してみたいですね。
そうするともっと建設的な議論になるのかな。 >>77はまず、１つのコメントに大量のレスを返すのを辞めてほしい
相手も同じペースで書いたらどうなるかを想像してほしい
技術者とはコードを書くだけが仕事ではないはず
特にアーキテクトなどのように上流工程にいくほど、コード以外の割合は増えていく
コードに対する美意識をほんの少しでもいいから普段の文章にも向けてみて欲しい
そして、>>77がこれまでに書いたコメントをアーキテクト的な視点で見直してみてほしい
これも「技術者としての自負を持つ」ために必要なことだろう
もちろんこれは自分にもいえることで、酷い文章だったと思う
それでも、論点を絞り、宗教論争にならないように気を付け、そして収束に向かうように
できるだけ努力したつもりだけどね
>>102
>実際オフ会とかでコードをもとに話してみたいですね。
>そうするともっと建設的な議論になるのかな。
この手の議論はかならず宗教論争になり、そして崩壊する
なぜなら君のような信奉者が現れるから
争いを煽り、特定の考えを絶対視し、相手の意見には耳を貸さず、相手を蔑む
君のコメントを読んでオフ会を開きたいと思う人はおそらく存在しないが、
ブログ等で発表することはできるし、必要ならここで宣伝すればいい コードなら説明できるというわりに、やたら「人」にこだわるんだな 現実の人に相手されないからここで吠えてんだろうなｗ Hibernateの人（仮称）には是非ブログを解説して欲しい。
そこで是非素晴らしい意見の数々を疲労してほしいな☆
てゆーか、どこかの会場を借りきって説明会開いて欲しい☆ どうも説明なしで>>82を間抜けと書いてしまったことがまずかったかと、気になっていたので
これの問題点だけ書かせてもらう
・「注文の登録」という具体的な例に、hoge, foo, model, otherEntityのような
意味のない名前が使われている
（特にotherEntityが何を想定しているのか分からない）
・「foo, bar」と「hoge, piyo」を混在させている
・ドメインモデルを説明するためにはドメイン層こそ例示すべき
・ドメインモデルの力を示すためには、ある程度複雑なドメインを扱う必要があるが
この例はスペースを考慮しても簡単すぎる
・サービス層のメソッド名として「persist」と「merge」は相応しくない
「register」等の名称（そして内容）にすべき
・アプリケーション層で行っている条件分岐は、サービス層の「register」内で行うべき
・「calculate」はおそらく「xxxOtherEntity」内で行うべき
（仕様上そうしてはいけない特別な理由があるのなら、その理由を明記すべき）
（また、特殊な場合であれば例として用いるべきではない）
重箱の隅をつついた嫌いはあるが、>>82のような極めて単純で小さなコード例にこれだけの
問題があることは珍しい。美意識が聞いて呆れる
あともう一つ、ひがさんの考えを「全面的に支持している」と書いたのはまずかった
あくまでも「シンドメインモデル」という考え方を支持しているということで、
ひがさん自身やSeasar2やS2Dao等の特定のプロダクトまで無条件で支持しているわけではない
また、Hibernateや「（リッチ）ドメインモデル」を否定しているわけでもない
※念のため、これらについて君と議論するつもりはない >>100-102
「トランザクションスクリプトを使う人は技術力が低い」という主張が
「複雑な業務ならドメインモデルを使えばいい」に変わったのなら
フレームのもとをなくしたという意味では事態は好転してるんじゃないかな。
話を帳票に戻して、どういう「複雑な業務」なら、
「管理帳票」をドメインモデルで適切に扱えるのだろうか。
>>56を読むと「一次キャッシュ」が決め手になるようだけど。
ちなみに俺は>>97に挙がっている本を教科書だと思っていないし、
オフ会に参加するつもりも無いので、それを理由に発言ごと無視してくれても良いよ。 >>103を書いてしまった手前、非常に心苦しいのだけど
見落としていたことがあるので>>108に追記させてほしい
>>82の例における>>89のポイントについて
そもそもDAOとはデータベースへのアクセスをカプセル化するものであり、
例えばHibernate用DAOからiBatis用DAOに交換したとしても理論上は全く同じように
動作するように設計すべきもの
（そもそもHibernateにDAOは馴染まないという意見もあるが）
>>89はそれを満たしていないばかりか、高度なO/Rマッパー特有の機能をDAOに
持たせたことを、素晴らしいことのように吹聴してしまっている
これではDAOを使うメリットが無いばかりか、手間が増し、混乱を引き起こすだけ
この例においてはDAOを使うのは明らかな誤り >>91
レスありがとう。明日から会社ですよ。
>重箱の隅をつついた嫌いはあるが、>>82のような極めて単純で小さなコード例にこれだけの
>問題があることは珍しい。美意識が聞いて呆れる
そういう所を見てたんですが・・・。
個人的には名称うんぬんはどうでも良くて考えてましたよ、少なくとも今は。
ごめんなさい。
↓のようなツッコミを想定してました。
で、これについて議論したかった。
>・アプリケーション層で行っている条件分岐は、サービス層の「register」内で行うべき
>・「calculate」はおそらく「xxxOtherEntity」内で行うべき
また、このコードをS2Daoで書いたらmergeの所に配管コードが量産されることを
このレスを見ている人に分かって欲しかった。そこを分かってくれる人と議論したいとも思ってた。
>あともう一つ、ひがさんの考えを「全面的に支持している」と書いたのはまずかった
>あくまでも「シンドメインモデル」という考え方を支持しているということで
できれば、91さんの考えを知りたいな。
「ER中心に考えてなぜドメインモデルが成立するのか」って結構証明が難しい問題だと思う。
シンドメインモデルっていうかリッチトランザクションスクリプトでしょう、と思う訳で。
まあ、用語はともかく、実際に複雑な業務をシンドメインモデルで表現した場合に発生する配管コードの量&重複コードの量と
(リッチドメインモデルを採用するのに比べて)実装・設計の簡単さという所のトレードオフなんかは自分も常々悩む所。 >>91
>>>103を書いてしまった手前、非常に心苦しいのだけど
>見落としていたことがあるので>>108に追記させてほしい
気楽にやってください。自分は基本的には何も気にしてないんで。
>>>89はそれを満たしていないばかりか、高度なO/Rマッパー特有の機能をDAOに
>持たせたことを、素晴らしいことのように吹聴してしまっている
>これではDAOを使うメリットが無いばかりか、手間が増し、混乱を引き起こすだけ
>この例においてはDAOを使うのは明らかな誤り
そう。そこ。そういう指摘が欲しいんですよ。
ドメインにロジック書くだけでワークできる程度の複雑さの業務だと、
hibernateでDaoがいらないケースが多い。
けど、サービスにどうしてもロジックを書かなくちゃいけないレベルの複雑さになると
Daoでクエリをカプセル化したくなるんですよ。ロジックと配管コードが混在して汚いから。
自分はそういう問題点が気になって仕方ないので、お客様には非常に申し訳ないけど
こっそりとDaoを使う場合、使わない場合で実験してたわけ、で結論としてはやっぱり
Daoを作った方が無難だということ。
なぜなら、後から想定以上に業務が複雑な事が分かってDaoが欲しくなったとき
リファクタリングするのが面倒だから、安全策で。ということなんですよ。
こういうのって、どういう風に考えてました？ >>99
>「トランザクションスクリプトを使う人は技術力が低い」という主張が
>「複雑な業務ならドメインモデルを使えばいい」に変わったのなら
>フレームのもとをなくしたという意味では事態は好転してるんじゃないかな。
ぶっちゃけ 「トランザクションスクリプトを使う人は技術力が低い」なんて一度も言ってないんですけどね・・・。
「hibernateでトランザクションスクリプトする奴はアホすぎる(その逆もそう)」とかは何回も言いましたが。
言い方が悪かったんでしょう。ごめんなさい。
>話を帳票に戻して、どういう「複雑な業務」なら、
>「管理帳票」をドメインモデルで適切に扱えるのだろうか。
>>>56を読むと「一次キャッシュ」が決め手になるようだけど。
帳票と言ってもそのシステムにおける重要度でモデリングは如何様にもかわるので、
前提がないと・・・なんですが。
例えば、帳票が主体のシステムだと、それがドメインとなるわけで、そのままドメインモデルで
表したらおkですよね。簡単な話。
問題は帳票が付属品みたいなやつ。
しかもメインのビジネスフローと異なった体系だったりする場合。
このときメインのビジネスフローをドメインモデルで表現すると、
明らかに確実に帳票はミスマッッチしまくりで破綻する。
で、こっから先は長くなるのですが、そもそもこういう回答の雰囲気で質問の意図満たしてます？
1次キャッシュとかいってるので外してたら怖くて。
>ちなみに俺は>>97に挙がっている本を教科書だと思っていないし、
>オフ会に参加するつもりも無いので、それを理由に発言ごと無視してくれても良いよ。
じゃあ何で、ドメインモデルって単語知ってんのよ！と強く思いますが、まあ、それはどうでもいいです。
99さんの教科書を是非示して欲しい。自分で言うのもなんだけど、ある程度の読書はしているので
よほどトリッキーなものでない限り大抵知ってるつもり。背景がわかると話が簡単になる場合が多いので。 >>104
>コードなら説明できるというわりに、やたら「人」にこだわるんだな
この手の議論て宗教論争になるのが常じゃないですが、
けど、コードレビューをもとに議論すると実はそんなに激しくならないんですよ。
もちろん「JavaでOOでシステムを作りたい」という前提の人との議論に限るのですが。
「Javaで構造化設計やりたい」という人とはやはり宗教論争になりますが。
ちなみに「トランザクションスクリプト= 構造化設計」ではないですから。誤認しやすいけど。
自分の理解だと、JavaでOOやりたい人はすべからくドメインモデル派なんだけど、
様々な事情で仕方なくトランザクションスクリプトやってる、と思ってるので。
>>105
>現実の人に相手されないからここで吠えてんだろうなｗ
逆かなあ・・・現実はある程度落としどころが見つかったんで、
ネットの皆様はどう考えてんだろうと思った次第。
>>106
>Hibernateの人（仮称）には是非ブログを解説して欲しい。
>そこで是非素晴らしい意見の数々を疲労してほしいな☆
>てゆーか、どこかの会場を借りきって説明会開いて欲しい☆
説明会の類いは仕事でずっとやってるので、一緒のプロジェクトになれたら是非w
ただ、自分が常にhibefnateを使うかというとそうでもないので注意が必要なのですが。
自分がアーキやってるときは、S2Dao 2: iBatis 2: hibernate: 3 RoR: 1くらいかな・・。
レガシーな時代を入れると↑は全然違うけど、直近だとこんな感じかな。iBatisも以外に多いですよ。
DIコンテナをspringにしてからはS2Daoは使ってないですね。当たり前だけど。
最近はJavaはおなかいっぱいでRoRに走ってるけど。
ブログはめんどくさいんですよね・・・。
ちょっとやってみようかなあ。 >>114
×
S2Dao 2: iBatis 2: hibernate: 3 RoR: 1くらいかな・・。
○
S2Dao 2: iBatis 2 springJDBC: 2: hibernate: 3 RoR: 1くらいかな・・。
でしたw >>113
> そもそもこういう回答の雰囲気で質問の意図満たしてます？
満たしてます。それが話の本筋だったはず。
>>56-57あたりからぐだぐだになって話が逸れまくったのでは。
こちらの背景は畑違いなのでどうぞお気になさらず。
>>52の問題提起に対する>>54の回答内容に疑問があって質問しただけです。
>>99
>満たしてます。それが話の本筋だったはず。
帳票が付属品の場合ですよね？
帳票が定時出力なのかオンデマンド出力なのかで変わりますが、
定時出力の場合:
帳票用のドメインモデルを作って、バッチかなんかで主要ドメインから帳票用のドメインに詰め替え&ロジック&永続化する。
で、帳票出力するときは、その永続化した帳票用ドメインモデルをそのまま出せばいい。
つまり、ドメインモデルが２つ存在するパターンです。
(ちなみに、帳票のロジックが全然たいした事ない場合はトランザクションスクリプトでもおkです。
実際はこっちのケースのが多いでしょう。)
オンデマンドの場合:
定時出力と同じでもいいんですが、設計上それが厳しい場合、
(テーブル作るのがいろんな理由でヤダとか、帳票出力アクション毎になんらかの処理をかませる必要があるとか)
帳票用のドメインモデル構築は諦めて、
DFDっぽく、inが主要ドメイン -> 変換ロジック -> out帳票用DTO(not ドメインモデル)しかない。
けど、これじゃ"変換ロジック"の所が手続き型のコードで汚くなるので、
そこをFWを使って美しくできるよう努力したほうがいい、
と言ってました。
ただ、これって正直ドメインモデルうんぬんというよりも、そもそもの設計の話だし、
1次キャッシュは全然絡まないわけですが、こういうことを質問してたんですよね。
>>>56-57あたりからぐだぐだになって話が逸れまくったのでは。
すいません。
ただ、ドメインモデル Vs トランザクションスクリプトを思想レベルから実装レベルまで議論しようとすると
どうしてもhibernateは避けて通れないと自分は考えてて、まずはこのスレにいる人がどういう人なんだろうと
思ってて。あんな感じにw。まあ、もうどうでもいいですが。 >>77
傍観者だけど質問、RoRってあなたの言う理想の形に近いですか？
>>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 ■ このスレッドは過去ログ倉庫に格納されています
