ドメインモデル VS トランザクションスクリプト
SQLがわんさか書かれた後に、DBの変更が頻繁に行われるので、生産性が著しく下がる。
PofEAAで解説されているドメインモデルでどうして実装しないんだろう？
俺が身近な人に聞いた理由：
１．難解なモデリングをするイメージがあるから（アナリシスパターンのせいか？）
２．どうすれば実現できるかわからないから（アーキテクチャが複雑になるから？）
３．業務アプリにドメインモデルは向かないから（イベントドリブンではないから？）
４．Hibernate(EJB3)が重厚すぎてトラブルが起きたときに怖いから（フレームワークのノウハウがないから？）
５．画面毎に実装させないと作れないから（開発者がへぼいから？）
俺はHibernateを使わずにDAO＋リッチなORマッピング処理を自動生成する方法
（Ruby On RailsのActiveRecordみたいなかんじかな）で開発するのが好きで、
それを使ったプロジェクトでは実際に、生産性も保守性も高いと思うんだけど。。
どう思う？
>PofEAAで解説されているドメインモデル
なにこれ。
ドメインモデルとは「エンタープライズアプリケーションアーキテクチャパターン」という本に出てくる
ドメイン（ビジネス）ロジックのアーキテクチャパターンです。
なにそれ。
フルO/Rマッピングかそうでないかってことを言いたいの？
単純に世の中勉強しない馬鹿ばかりだからじゃない？
Eric EvansのDomain Drviven Designはもう読んだ？
>>7
全然違うよ。
ttp://www.ogis-ri.co.jp/otc/hiroba/index.html
フルO/Rマッピングが何を指すのかがちょっとわからなかったので、YES、NOといえないのですが、
RDBのロウを継承構造のオブジェクトにするだのといった、変換についての話はどうでもいいです。
ドメインモデルかトランザクションスクリプトか？という問いたいのは、
・ドメインモデルがわかるかわからないか
・ドメインモデルを使ってるか使ってないか
・ドメインモデルが好きか嫌いか
理由を含めて知ることで、トランザクションスクリプトとドメインモデルの理解が深まるのではないかなぁ。。と思いまして。
リーダーとかアーキテクトしてる人は少なくとも勉強してるんじゃないのかな？
DDDは流し読みしたよ。
2章までは楽しく読めたんだけど、それ以降はテストコードばっかり
書かれていて、実装の全体像が明示されていないから、わかりにくいと思った。しかも.Netだし。。
考えるネタにはなるけど、これを読んでドメインモデルのシステムを作るのは
無理じゃない？
僕はDAO＋自前のOR変換＋レイジーロードのアーキテクチャで作っておいて、
チューニングが必要な所をイーガーロードにしていくので、エバンスさんとは好みが違うから余計に
否定的に思ってしまうのかも。
ごめん、DDDを思いっきり勘違いしてました。
「ドメイン駆動」がDDDの邦訳版だと思っていたんだけど、違うんですね。
ちょっと調べてきます。
「ドメイン駆動」にたいするものでした。すまん。。
早速明日読んでみます。
勘違いに気づかせてくれた8さん、ありがとうございました。
いえいえ。
DDDはまだ日本語に翻訳された版がないので、英語に弱いと割と読むの、大変かも。
PofEAAは日本語に翻訳もされてるよね。
読んでます。が。。。使われている英語難しいですね〜（＾＾；
ひたすらわからない単語の意味を本に書きこんでいますが、
文章にしたときに意味がわからない事が多々あります。
でも、とにかく読まないとドメインモデルを語れなさそうなので、
地道に読んでいきますね。
もしよろしければDDD読んだ感想をお聞かせいただけますでしょうか
それぞれどのような場面で有効なものなのかを書けや。
＞ドメインモデルとトランザクションスクリプトについての説明と
＞それぞれどのような場面で有効なものなのかを書けや。
簡単に言うとトランザクションスクリプトは手続き型だね。
手続き型なんて、今さらなんで議論してるかって、エンタープライズアプリがいつまで経っても手続き型から脱却ができないから。
ドメインモデルは。。。
まぁ皆さん勉強しましょう！
取り敢えず一番理解しやすかった説明はこんなんだが、こういうことなのか？
ttp://csharper.blog57.fc2.com/blog-entry-170.html
要するにこれまでデータのまとまりでしかなかったEntityがLogicも包含すると。
そんな簡単な訳ねーよな。
ドメインモデル貧血症の理解は入り口に過ぎず。
2chで理解しようってのは無理なんじゃ？
>EntityがLogicも包含すると。
アーキテクチャとしての違いの基本はそうです。つまりオブジェクト指向にするということです。
関連とは手続き型でいうと構造体に別の構造体の変数を持っている感じです。
手続き型であるトランザクションスクリプトでは、ServletやActionやServiceやLogicといった
処理専門のクラスがDaoを呼び出した結果を、この構造体にデータを詰め込みます。
当然ながら詰め込んでいない構造体のデータは参照しても値が取得できません。
例えば、Employee has Department has Companyという構造だとして、
処理専門のクラスがEmployeeとDepartmentしかデータを詰め込んでいない場合、
(Employeeのインスタンス)e.department.companyはnullになってしまいます。
関連するModelインスタンスにデータを詰め込む処理は、Modelクラスの中に実装します。
例えば関連する情報を参照された際にModelクラスのゲッター内でDaoを呼び出します。
これにより関連する情報を無限に辿ることができるネットワークが構築できます。
例で言うと、処理専門のクラスがEmployeeのインスタンスを取得した後、
（Employeeのインスタンス）e.getDepartment().getCompany()を実行するだけで結果が取得できます。
じゃあドメインモデルは何かというと、この無限に辿れる構造のModelクラスにビジネスロジックを実装したものです。
これで何が改善されるのかというと
・関連するデータを無限に辿れるため、画面の変更に強い。
・Modelクラス郡でカプセル化された中にビジネスロジックが記述できるため堅牢になる。
・Modelクラスを現実世界に近い状態で表現できる。
・画面毎にSQLを記述する量が減るため分業しやすい。
逆にデメリットとして
・アーキテクチャが複雑になる傾向がある。
・実際には完全なカプセル化は無理なので、ある程度開発ルールで縛る必要がある。
・単純に実装するとパフォーマンスが悪くなる。
・オブジェクト指向がわからない人にはModelクラスを全く設計も実装もできない。
21さんが言うように、現状、最後のデメリットが一番のネックで広まらないのかもね。。
少し論点が特定のものに行き過ぎてる。
Martin FowlerのGetterEradicatorという記事をご覧あれ。
取り敢えず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のプロジェクトで下で実例みさてもらいたいもんだ。
ご意見ありがとうございます。
GetterEradicatorを読んでみました。
26の説明がpublicなゲッターを用意しないとドメインモデルが構築できない
と誤解を招くということですね。ごめんなさい。
ところで、GetterEradicatorを読んでどうもしっくりきません。
ドメインモデルはビジネスロジックをOOPで実装することですから、カプセル化が
重要なこともわかります。ドメインロジックのメソッドだけが公開されるべきだと。
でも、実際にシステムを作ってみると、関連を辿って画面に表示するだけの
処理がかなりの割合を占めているし、更新処理でDaoに関連する情報を
公開する必要があるので、要件としても、アーキテクチャ的な制約としても
publicなゲッターを用意せざるをえないと思うのです。
Martin Fowlerを超えた思考ですね。
笑
いきなり制約から考えるより、まずはどうあるべきかを考える方がよいですよ。
日本人は、言語やフレームワークは使うものと思いがちですが、理想のためにはルールを変えてしまえばいいのです。
アドバイスありがとうございます。
確かに経験則にとらわれてしまうのはよくないですね。
カプセル化をするには、プレゼンテーション層向けのインターフェースを
用意して、それを使わせるルールにするのが一番簡単だと思いました。
>>33
あはは（＾＾；独特な言い回しが多いので理解するの難しいですね。
自己レスです。
JSTLとかのTaglibはリフレクションしまくりで、インターフェースを
経由できないから結構穴が大きいですな。
選ぶべきなのかな。。
まずは画面やデータベースを考えず、ドメインだけを考えた場合の理想的な形を考えてみたらどうですか？
英語と日本語の壁が大きすぎるのだろうな・・・
ネイティブの人はいいな。
まじめに技術的プログラミングが出来て。
日本なんか、作業だからなｗ
何も考えちゃいない。
物が来た→処理。
理想的な形というのは、
画面やアーキテクチャを無視して、理想的なドメインのモデリングをせよということですか？
それとも、ドメインモデルを中心にして考え直せば、理想的なアーキテクチャが導き出せるということですか？
http://www.infoq.com/jp/minibooks/domain-driven-design-quickly
http://msdn.microsoft.com/ja-jp/magazine/ee236415.aspx
ネタ投下。
こないだ新規システムでアーキテクトやらせてもらえたから、ドメインモデルでやったんだ。
ASP.NET/C#2.0な構成。
俺は最初にコア部分作って後は別の人（外注）だったんだが、出来上がったもの見て落ち込んだ。
テストケースが空メソッドだらけな上にドメイン貧血症っていうかほとんどbean。
コーディングは各々の裁量に任せてたから、結局は俺の指示に不備があったんだと思うんだが、まぁそれはいいとして。
ドメインモデルで組まれたプロジェクトが上手く回った経験あるやついたら聞きたいんだが、末端のコーダーまでドメインモデルのなんたるかを知ってないとうまく回らんかな？
仮に知らなくてもいいって場合でも遵守させることとかあったら聞きたい。
日本の平均的な技術者のレベルが低いなぁと常々思う。
一カ所のプログラムのみが肥大化することが多い。
必要な業務処理に対して、
その全体を一つの関数なりメソッドなりに収めようとするから
いわゆるトランザクションスクリプト的な作りになっちゃうんだよね。
書く奴曰く、その方が見通しが良くて判りやすくシンプル、だそうな。
機会があったら保守についてどう考えてるか聞いてみてくれ。
「その方が見通しが良くて判りやすくシンプル」
なんだったら、そっちの方が保守性高くね？
Javaでこんなのないの？
理想形がわからない。
どうしても帳票とドメインオブジェクトのリンクを考えてしまう。
DDD読んでても「いや、だから帳票どうすんだよ帳票」とか考えてしまう。
といって、帳票をベースにしてしまうと双方向参照が生まれやすいし、
正直、オブジェクト指向的じゃないと思う。
でも帳票ベースじゃないと、画面表示で死ぬ。
うーん、帳票どうすればいいんだよ。
特に普通に組んだらLEFT JOINが8回位発生しそうな管理帳票。難しい…。
ドメインに特化して、データを構成させるのだから、
ドメインをまたがった帳票を作ろうとすれば、おのずと外部結合が多発するのは仕方ないと思うよ。
そのデメリットをもってしても、拡張しやすいデータ構造には勝てないと思う。
どうしても、外部結合の多発を嫌うのなら、ドメイン単位でビューを作ってやれば、見た目はすっきりするかもしれない。
ドメイン内では、内部結合になるだろうから。
そこまで大げさなものが不要であれば、derived-table（inline view)にするのとかかね。
常にドメインモデルマンセーにするのではなく使い分けも肝心かと。
帳票系は出力内容・タイミング（日次、週次、オンデマンド）にもよるが、ドメインモデルとは別に帳票用の非正規化したテーブル（パフォーマンスが許すならビューでもよい）を作成したほうがシステムとして美しい場合もある。
どうしてもドメインモデルをそのまま帳票に当て込みたい場合は、粗結合を極限まで追求したコンバーターなどを作成し、オブジェクトグラフの変換を簡易化する方向にパワーを使った方がいい。
帳票を問題としてあげてるが、例えば他システム連携などでもおそらく帳票と同様の問題が発生するわけで、もうこれはケースバイケースで、モデラーのセンスを信じるしかない。投げやりな回答で申し訳ないが。
コアのコードがイマイチなのが原因かもしれない。
プロジェクトの規模によるが、外注さんは原則としてコピペでプログラムを作成する。
であればコアのコード(フレームワーク部分、ドメイン、フレームワークを使ったプロトタイピング)がドメインモデルを意識したプロジェクト構成、
レイヤリング、パッケージング、コーディングスタイルになっていれば
必然的に外注さんコードもそれに準じることになる。
もう一度自分の作ったコアなコードを見直した方がいい。
それでも、コアのコードに絶対の自信があり、外注さんのスキルが一方的に低いというのであれば、
コードレビュー・ペアプロを通して教育するしかない。
ただ、これまでの経験上外注レベルの低さに苦言をいうアーキテクトは
大抵フレームワークのなんたるかをわかっていない低スキルの輩が多かった。
>（Ruby On RailsのActiveRecordみたいなかんじかな）で開発するのが好きで、
>それを使ったプロジェクトでは実際に、生産性も保守性も高いと思うんだけど。。
私もこれに関しては死ぬほど悩んでいる。
hibernateでオブジェクトのグラフ構造とDBの表構造をマッチングするのはOK。これについては100%生産性が高いといえる。
しかし、真にドメインドリブンアーキテクチャを追求した場合、1次キャッシュによるユニットオブワークを最大限利用する必要がある(勝手にアップデートって言った方がいいか？)
これはドメインモデルの観点からすると非常に有意義な機能だが、「普通の開発者」にとっては理解しがたい機能のはず。(EJBやってればわかるんだろうけど)
1次キャッシュはhibernateの必須機能のため原則として無効化することはできないが、ラップすることでどうとでもできる。
で、結論としては開発者がユニットオブワークを理解できるのなら、hibernateを使えば良い。難しいようであればS2DaoやiBatisのようななんちゃってO/Rマッパーを使った方がいい。
だがそのなんちゃってO/Rマッパーが一番使い易い。
どうせフルO/Rマッパーなんて速度も出ないし、
複雑なことしようとしたかったらSQL書かなくちゃいけないし、
そもそもフルO/Rマッパーなんていらねーんだよ。
そんなに永続化データをオブジェクトで扱いたいなら
オブジェクトDB使えよチンカスカス。
少数精鋭でやる小さな案件ならぶっちゃけ何やってもいいと思っているけど、
規模が大きくなればなるほど「普通の開発者」の占める割合が大きくなる訳で。
今の低予算かつ短納期なご時世では育成、教育にかける余裕が全然ない。
となると、より理解しやすい方を採用するのは必然じゃないかな。
ついでに、開発が終わった後は運用保守フェーズに入る訳で、「普通の運用保守担当者」が理解しやすいかどうかも大切だよね。
>だがそのなんちゃってO/Rマッパーが一番使い易い。
>どうせフルO/Rマッパーなんて速度も出ないし、
「フルO/Rマッパー = パフォーマンスダメ」っていう議論はかなり飛躍しすぎだと思う。
これだと、なんちゃってO/Rマッパーを使えばパフォーマンスがでると誤解されかねない。
フルO/Rマッパーを考慮したクラス設計、ER設計にしなかった場合にパフォーマンスが劣化する、ってのが正しい。
で、この手の議論は大抵hibernateやJPAなどを「なんとなく」使って火傷した人が吹聴する場合が多い。
そうなる気持ちは十分わかるので、あまり強く突っ込みたくないけど、技術者ならもうちょっと勉強した方がいいと思う。
>複雑なことしようとしたかったら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使えっての少々議論不足。
んなこたーない。
hibernateが吐き出したSQL見ると酷いぞー
AとBというテーブルをJOINして一覧取得したいだけなのに
AとBをJOINしたものをさらに副問い合わせでくるんでSELECTしてた。
設計がどうたらのレベルじゃねぇの。
＞正確に言えばO/Rマッパーは原則としてSQLを書かない。
＞オブジェクトグラフを操作するクエリを書く。
＞一見似ているので誤解されやすいけど、根本的に違うものなので注意した方がいい。
＞プログラムではオブジェクトとして扱うのだから、永続化や抽出処理もオブジェクトとして扱いたい
＞というのがO/Rマッパーの本質。
だから無理にRDB使わなくていいじゃん。
＞なんで、O/Rマッパーは永続化先のストアはファイルでもKVSでもDBでもオブジェクトDBでもなんでもよい。
＞なんでもマップできますというのがO/Rマッパーの特徴。
DAOパターンでそれできてますけど。
>んなこたーない。
>hibernateが吐き出したSQL見ると酷いぞー
>AとBというテーブルをJOINして一覧取得したいだけなのに
>AとBをJOINしたものをさらに副問い合わせでくるんでSELECTしてた。
>設計がどうたらのレベルじゃねぇの。
いや、だから、なんでそういうSQLになるのかを考慮して設計する必要が
あると言ってるわけです。（ただ、この例であれば
フェッチ方法を変えるだけで解決しそうだけど）
なんで、そういう考慮をしたくないのであれば、hibernateを使わず、S2Daoを
使えばよいとも言ってます。
60でも書いたけど、hibernateを真に使いこなすには
「O/Rマッパー&モデリング&ER設計」の熟練者が必要。
極論すぎ…。
例えば、DBとKVSをハイブリッドで使用するケースは結構あると思うけど、
オブジェクトクエリによってこれらリソースの差異を吸収するわけです。
>DAOパターンでそれできてますけど。
DAOパターンではDAOクラスによってリソースの差異を吸収するけど、
ここではオブジェクトクエによってリソースの差異を吸収します。
だから、レイヤーのポイントがちょっと違う。
DBとKVSをハイブリッドにした場合、
DAOパターンではDB用のDAOとKVS用のDAOを作る必要があるけど、
O/Rマッパーではオブジェクトクエリがそれを代用してくれる。
＞「O/Rマッパー&モデリング&ER設計」の熟練者が必要。
O/Rマッパーの意義の根幹を覆す発言だな。
そんなに苦労しなきゃいけないのなら使う必要ないよ。
根幹を覆す発言ではなくて、O/Rマッパーを使いこなすにはそういうスキルが必要と
オフィシャルなドキュメントにも書いてある。
つまり、これらは前提。
O/Rマッパーを使う意義については60で書いたとおり。
この意義がどうしても納得でいのならhibernateを使わなければいいだけのこと。
問題なのはこういう前提をしらずに「なんとなく」使って火傷して「使えねえ」と
非難する人間。技術者なら実装レベルだけでなく、設計レベル、思想レベルでアーキテクチャを
評価したほうがいいと思う。
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が有用であることは否定しないが、全体的に現実の問題を無視して
過大評価になりすぎている
O/Rマッパー、モデリング、ER設計の熟練者が必要でとかって
敷居が高くなってたら本末転倒過ぎだろｗ
しかもSQL直接書かないのが前提だから速度出ないしｗ
S2DaoとiBatis意外考えられんわ。
>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を使う人の思考回路でしょう。
簡単に"実装できる"ということは大事だけど、それ以上にアーキテクチャには一本筋の通った思想が必要だということ。
だから一番嫌いなのが、ERを中心としたアーキテクチャにしているのにhibernateを使用すること。
また、逆にオブジェクトを中心としたアークテクチャなのにS2DaoやiBatisを使用すること。
そういう意味でここでは思想に関しての比重を重めに話している。
だから、思想なんてともかく、とにかく簡単にやりたい人はS2Daoを使えばよいと言っている。
>Hibernate等なら、さも簡単にできるかのように書かれているが、少なくとも現時点では
>実現できていないはず。当然、移植性も特段高くはない
実現できていないはず、と言われても困るわけで、何をどう実現できていないのか書いて欲しい。
過去の経験上、MySQL、PostgreSQL、Oracleでは同一のコードで動作したし、
同時に、2次キャッシュとしてKVSを利用しても問題なく動作してる。
>移植性を高めるには>>61のいうようにDAOを使い分けるのが現実的な対処法だろう
>これに対し、"レイヤーのポイントが違う"という指摘はあまり意味が無い
hibernateはオブジェクトを中心としたアーキテクチャのため、リソースの違いをオブジェクトクエリで吸収している。
というのがここでの言いたいこと。
それをDaoパターンでできます。と言われれば、もちろんその通りなのだが、
質問者が「リソースの違いをオブジェクトクエリで吸収している」という大事なアーキテクチャのポイントを理解して
いなかったぽいから補足しただけのこと。
>本来は単なるツールであるのに、その美しさや理想のために実装を
>犠牲にするのなら本末転倒だろう
とはいっても、思想のないアーキテクチャも駄目でしょう？
これはバランスの問題で、アーキテクトがプロジェクト初期の段階でジャッジする事柄でしょう。
>FWって本来は実装を簡単にさせるってのが役割なはずなのに
>O/Rマッパー、モデリング、ER設計の熟練者が必要でとかって
>敷居が高くなってたら本末転倒過ぎだろｗ
これはアーキテクトの仕事。
たぶん。あなたの仕事じゃないよ。
メンバーはドメインを作ることはないだろうから大丈夫。
>しかもSQL直接書かないのが前提だから速度出ないしｗ
もうちょっと過去ログを見るなり、なんなりした方がいいと思う。
技術者として本気でそう思ってるのなら、さすがにキツイと思う。
煽りで書いているのなら反応した自分を恥じるけど。
>S2DaoとiBatis意外考えられんわ。
そういう人はS2Daoを使えばいいと思うよ。
なにも使うななんて一言もいっていない。
自分もドメインがシンプルなプロジェクトではiBatis使う場合があるよ。
>ドメインモデルと ORM って無関係だよね
机上レベルだと無関係。
だけど、それを実装レベルに落とし込んだとき、ちょっと関係してくる。
というもの。
>>O/Rマッパー、モデリング、ER設計の熟練者が必要でとかって
>>敷居が高くなってたら本末転倒過ぎだろｗ
>
>これはアーキテクトの仕事。
>たぶん。あなたの仕事じゃないよ。
>メンバーはドメインを作ることはないだろうから大丈夫。
いやいや、Hibernateなんかは実装もかなり面倒だったぞ。
副問合せどうすればいいのよみたいな。
ま、普及することはないべ。
副問い合わせする方法なんて、公式のリファレンスを検索すれば5分でわかると思うよ。
調べるのが嫌とか、新しく覚えるのが嫌というのであれば仕方ないけど。
普及はともかくとして、せっかくなんで書籍の一冊くらいはちゃんと読んだ方が
技術者としての懐が絶対に広くなると思うよ。
それすらを求めないのなら、そもそも議論に参加しない方がいいと思う。
>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といえど今は真面目に話をしてるわけだから
>それはおかしいでしょ
>Hibernate等がO/Rマッパー＋αの機能があること表現するために、O/Rマッパーとしての
>機能を十分に備えた他のものを"なんちゃって"と表現する人はいない
思慮の足りない名称ですいません。
正直、名称はどうでもいいので、何か適切な言い方を提案してください。
ただ、古いEJBをやってた人間からすると、O/Rマッピングには主に二つの機能があって、
グラフ構造 <-> 表構造のマッピング(静的な構造のマッピング)
オブジェクトインスタンス <=> レコードの内容(ステートのマッピング)
があるので、S2Daoなんかはどうしてもなんちゃってに見えます。
で、それが悪いなんて一言も言ってないので安心してください。
>思想を語るのは大いに結構だが、他の人が現実の問題の話をしているのだから現実から
>離れた話をするときは何らかの前置きはするべき
>>56で
「真にドメインドリブンアーキテクチャを追求した場合、1次キャッシュによるユニットオブワークを最大限利用する必要がある(勝手にアップデートって言った方がいいか？)」
と書いたつもりだったんですが、もう少し具体的に書けばよかったですね。
>RDBに関しては動作して当然でしょう
>KVSに関しては>>60の文脈からすると、メインの永続化先としてRDBと何ら変わらずに
>使えなければおかしいが、それはできていないということ
永続化先にファイルは確かに言い過ぎで、そもそもマップする必要がないですね。
ただ、DB<->KVSについてはあります。この場合、現実的な解としては
メインの永続化先としてDBを、2次キャッシュとしてKVSを採用した方が
ワークしやすい(ノウハウがある)のでそうしてるだけです。
>それから、この例だけでは>>60であげていた移植性の明らかな優位も認められない
75のいう移植性とは何でしょうか？
私がここでいう移植性とは「リソースごとにコードを作成する必要がない」といものです。
もう少し詳しく言うと「コードを作成する必要がない」のはサービス層の話で、
core層(ここではhibernate)などでは死ぬほどがんばります。
DAOパターンは特殊なコーディングをしない限り、原則としてリソースごとにコードを作成する必要があるでしょう。
>あとついでに、ちょいちょい出てくる人を見下した表現は気を付けた方がいいよ
>読んでても気分よくないし、2chといえど今は真面目に話をしてるわけだから
真面目に話している人には真面目に回答しているつもりです。
>>61、>>64、>>68、>>73なんて、若干煽りも含んだあまりに低レベルな書き込みなので
それ相応の回答したまでです。
なんていうか、このスレはドメインモデル vs トランザクションスクリプトなわけで、
必然的に「ドメインモデル派 = hibernate」「トランザクションスクリプト派 = hibernate以外」という構図が自分にはある。
ここでhibernate嫌だと言ってる人はトランザクションスクリプト派ってこと？
ドメインモデルの何たるかを知らんヘボ外野だけど、
煽りに対して、同レベルの煽りや極論で返すのはダメだってばっちゃが言ってた。
その時の構成を書きますね。
レイヤーは以下の通りにわけます。
インテグレーション層(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();
}
}
>があるので、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からで、一貫して同じ印象を持っている
それと、低レベルなとこまでわざわざ合わせてくれなくていいから
そもそも無理がある。
だからインピーダンスミスマッチなんてものが発生する。
希望としてはもうHibernateに代表されるフルO/Rマッパーなんてものは
無くしてしまって、RDB使う場合はS2Dao、iBatis系のO/Rマッパーを使う。
どうしても永続化データをオブジェクトで扱いたい場合は
オブジェクトDBを使うという風にならんかね。
>意味不明すぎて全く安心できない
最近のO/Rマッパの定義はともかく、初期のJavaでのO/RマッパはEntityBeanでその定義を正とすると
S2Daoは機能が足りてない(省かれている)と言ってるだけですよ。
ほんとそれだけです。
で、機能が足りないから悪いなんて言ってないし、見下したりもしてないですよ。ほんと。
なんでこんなどうでもいい所を気にするか正直わけわからんのですが。
>ここでも何を言っているのか分からない
>そもそも、説明として"死ぬほどがんばります"は酷過ぎる
>何をどのように頑張るのか？
>"死ぬほど"なのに移植性が高いことの説明になっているのか？
システムには大きく分けると「業務に依存したコード」「業務に非依存のコード」ってありますよね。
Daoは大抵の場合「業務に依存したコード」になりますよね。
hibernateは「業務に非依存のコード」になりますよね。
ここでDaoパターンを使うと「業務に依存したコード」に外部リソースへの依存関係が混入します。
対してhibernateを拡張すれば「業務に非依存のコード」を改修するので、「業務に依存したコード」はポータブルです。
ということを言いたい訳です。
この説明でも納得してもらえないでしょうか？
先に書きましたが、
Hibernateを使ってトランザクションスクリプトにする人はかなり軽蔑します。
S2Daoを使ってドメインモデルにする人も軽蔑します。
というのであって、トランザクションスクリプトを軽蔑なんてしてないですよ。
自分も駆け出しの頃はガリガリのトランザクションスクリプトでした。
ただ、JavaはOO言語なわけだから、インヘリタンス、ポリモーフィズム、カプセル化でシステムを構築したいと思って
ドメインモデルに走った訳です。(その背景にはC時代の構造化設計で限界を感じたこともあります)
>はじまりは>>56からで、一貫して同じ印象を持っている
>それと、低レベルなとこまでわざわざ合わせてくれなくていいから
それはすいません。
ただ、個人的にドメインモデルって言ってるのにhibernateをイマイチよくわかってないっぽい輩がいるので、
気分的にはうんざりした感じなってます。
冗談抜きに、普通ドメインモデルでシステムを構築したいって言ったら、1次キャッシュありのO/Rマッパー使うでしょ？
使わないって言ってる人はいったいどういうアーキテクチャにするつもりなんだろ、と思ってます。
そこを説明してくれたら結構うれしいかもしれません。
LL言語で使いたいだけなんだけど
仕事だと口よりもコードで説明するタイプなので、ある意味楽ですよ。
私に聞いてもらえばコードで答えを返しますから。
そのコードが気に食わなければ修正してもらえばいいので。
そういう意味で、この掲示板では言葉で言い過ぎたので、
>>82でコードを書いたわけですが、これを見て何か思う所があったらぜひ突っ込んでください。
特に↓あたりなんて、1次キャッシュありだからこそできる技なんで、こういうスタンスでコードを書いてる人は
ぜひ意見を欲しい所。
modelDao.merge(model);
model.refreshOtherEntity();
model.calculate();
LLでドメインモデルを作りたいときってどういうシチュエーションなんでしょう。
つまり、「LLで複雑な業務をモデリングする」ということになるわけですが、
そういうシステムってどんなのなんでしょうか。
この辺はあまり経験がないのでモチベーションを含めて説明してくれるとハッピーです。
あ、ちなみに、89は自分です。
>ほんとそれだけです。
>で、機能が足りないから悪いなんて言ってないし、見下したりもしてないですよ。ほんと。
>なんでこんなどうでもいい所を気にするか正直わけわからんのですが。
どうしても分からないんだけど、この３行は必要なの？
>>84で意味不明と書いたのも「"なんちゃって"と表現するのはおかしい」という指摘に対し、
「安心してください」と返ってきたことに対して。
こういった無駄で相手を不快にする表現を減らせば、中身のない返信に２レス・３レスを
費やす必要もないんじゃないかな
>ということを言いたい訳です。
>この説明でも納得してもらえないでしょうか？
残念ながら…
でもこれ以上はもう結構
>Hibernateを使ってトランザクションスクリプトにする人はかなり軽蔑します。
>S2Daoを使ってドメインモデルにする人も軽蔑します。
最初は人間的に問題はあるが、おそらく技術力は高く仕事はできるのだろうと想像していたが
>>86のような間抜けな例や、論理性の欠片もない返答を見ると、どうも間違いだったようだ
>使わないって言ってる人はいったいどういうアーキテクチャにするつもりなんだろ、と思ってます。
>そこを説明してくれたら結構うれしいかもしれません。
これに関しては、S2Daoの開発者でもある、ひがやすをさんの考え（シンドメインモデル）を
全面的に指示している
（リッチ）ドメインモデルや、>>87があげたOOの利点を十分に活かしつつ、テストや
保守といった現実の問題にも十分に対応できる柔軟さがある
詳しくは氏のブログを参照
念のため書いておくが、この件について君と議論するつもりはないよ
× >>86のような間抜けな例や、論理性の欠片もない返答を見ると、どうも間違いだったようだ
○ >>82のような間抜けな例や、論理性の欠片もない返答を見ると、どうも間違いだったようだ
ひがさん支持のひとでしたか・・・。
いや、なんとなくそういう気がしてたのですが。
Spring VS Seaserの議論も大抵こんな感じになりますよね。
それはともかく、ひがさんも
http://d.hatena.ne.jp/higayasuo/20080201
の「HibernateとS2DaoとS2JDBCの考え方」で
hibernate = Entity中心
S2Dao、S2JDBC = ER中心
と書いてるので「ER中心だけどドメインモデル」っていわれると、
「なんだそれ？」と思う訳です。新手のセールストークかって？
なにをどうドメインモデルなのかと。
というより、ほんとにドメインモデルでシステム作った事あんのかと思います。
きっとないでしょう。ないからこんな事が言えるわけで。
そういう意味で、91さんとは根本的にポジションが違いますね。
無用な議論ほんとにすいません。
しかし、Seaserラブな人はどうしてhibernateが嫌いなのだろう。
現実でもネットでもみんな嫌いって言ってる。
springはそこまでじゃないのに。
多分ひがさんがhibernate嫌いだからそれにつられてるんだろうけど、
なんだか主体性のなさを感じる。右向け右みたいな。
比嘉さんの言葉を完全に鵜呑みにするんじゃなくて、
もう少し自分で評価して、自分なりの意見を言えばいいのに。
手を動かして複雑なドメインのものをS2Dao、hibernateでそれぞれ実装して、
それで評価すれば簡単なことなのに、それすらしてない人が多い。
してないのに、hibernateは駄目だ。という。
で、何が駄目なのかと一つ一つ問いただしていくと、
結局シングルテーブルマッピングすら理解していなかったりする。
(これは極端な例だけど、感覚として7割以上の人間は1次キャッシュすらわかってない)。
それで、なぜhibernate、ひいてはドメインモデルのなんたるかを非難できるのかと。
スレ汚してほんとすいません。
ただ、技術者だったらもうちょっと自負をもってアーキテクチャを構築して欲しくて・・・。
俺俺アーキテクチャが理解できる人なら俺俺アーキテクチャで開発するのがベストだ。
これが俺様の結論。俺俺アーキテクチャは100%理想的で完璧だ。
しかし、俺俺アーキテクチャは「普通の開発者」には理解できない。
理解が難しいようであれば、巷のアーキテクチャのような、
「なんちゃって俺俺アーキテクチャ」を採用するしかない。
俺俺アーキテクチャが何故だめなのか。反論に主体性の無さを感じる。
俺俺アーキテクチャを使ってもいないのに非難する。
非難するやつの7割は、結局、俺俺キャッシュすらわかってない。
技術者だったらもうちょっと自負をもって俺俺アーキテクチャを賛美して欲しい。
レスありがとう。
ちょっと抽象的な内容なので理解していないところもあるけど。
>俺俺アーキテクチャが理解できる人なら俺俺アーキテクチャで開発するのがベストだ。
>これが俺様の結論。俺俺アーキテクチャは100%理想的で完璧だ。
>>82で示した例って、俺俺なんてほとんどなく、
J2EEの5層モデルをドメインを中心にリファクタしただけなんですよね。
これを見て「ああ、５層モデルを参考にしてるんですね」ってのが模範解答で、
更なるリファクタポイントを提示してくれるのが、うれしい回答。
最近は5層モデルなんてどうでもいいのかなあ・・・。
3層と5層を混同してる人が多すぎだし、なんだかなあと思ったりする。
だから、そういうそもそもの前提がない人に非難されると腹が立ってツイ・・・
>俺俺アーキテクチャが何故だめなのか。反論に主体性の無さを感じる。
>俺俺アーキテクチャを使ってもいないのに非難する。
>非難するやつの7割は、結局、俺俺キャッシュすらわかってない。
>技術者だったらもうちょっと自負をもって俺俺アーキテクチャを賛美して欲しい。
なんていうか、まず議論する前に自分の背景を提示した方がいいですよね・・。
自分はEJBデザインパターン、J2EEデザインパターン、
エンタープライズアプリケーションアーキテクチャパターン、ソフトウエアアーキテクチャ、インテグレーションパターン
なんかの割とメジャーな書籍でアーキテクチャの何たるかを勉強しました。
(細かい書籍をあげると+20くらいなりますが、まあ内容はだいたい似通ってるので)
なんで、逆に比嘉さんのいうアーキテクチャがあまりに俺俺すぎで(=これらの本で提示されている内容と逸脱してる場合が多い)、
それを採用する人は、もうちょっと勉強してみてそれで判断したら？って思うんですよ。
そういう前提があって比嘉さんの意見に賛同なら全然かまわないんですが、
ほとんどの人はそうじゃないんですよね。それなのになんでみんな強気なんだろうと。
技術者としてそれでいいの？って。そんなにアーキテクチャって簡単なの？ってものすごく疑問に思う訳で・・・。
で、>>94は間違い>>95が正解でした。
あなたの発言自体が中傷的(変換ﾜﾛｽw)かつ独善的で、
たぶんまわりは全然理解できてないですよ。少なくともROMしてた俺にはわからない。
それをあなたは「技術者としてどうか」みたいに見下して言ってるけど、
まずはあなたの俺俺な部分をきちんと説明してはどうですか。
という事を指摘したつもりなんだけど、>>97の回答を見る限り、
問題の根本が伝わってないように見える。
自分の知っているものなら正しくて、そうでないものは俺俺なように見えてるんでしょ。
スレタイにVSとあるけど、対戦相手はあなたが自己中心的に喚いているように見えるわけです。
あなたの背景の確認として、97=77=59=56=54、という事でいいんだよね?
>>56にあなたが書かれた「結論」というものはひどい内容だと思う。
>>59にも「火病ってる」「相手の技術力が低い」という旨の発言をすでに書かれている。
でも>>57の発言を否定できていないよね。むしろ>>54で肯定してるよね。
都合の悪いことを人格否定で濁していて、肝心の議論がおろそかになっているように見えるよ。
>>57の言葉遣いが悪いのは、>>56がフレームのもとになる発言をしているからだ。
そのあたりを見直した上で、>>54とか>>59あたりの反論内容から具体的に書き直して欲しい。
あなたの発言を見ていると、
「ドメインモデルをRDBで採用するには非正規化したテーブルを沢山作る必要がある」
と言っているように見えて、それはあまりレベルが高いアイデアには見えない。
レスありがとう。
言葉で説明するのは複雑ですね。
コードだと楽勝なんですが・・・。
>>まずはあなたの俺俺な部分をきちんと説明してはどうですか。
俺俺な部分・・・。
>>97で示した書籍がバックグラウンドで、これらがこの世界の教科書だと思ってます。
で、このスレに書き込む人はこういう書籍を一通り読んだ上で実践してるもんだと思ってます。
アーキテクトなら当然の責務とすら思ってました。
(実際、現実のアーキテクトと名乗る人はほぼ100%は読んでて、ちゃんと理解してる)
Seaserは2年くらい使ってて、比嘉さんのブログは毎日見てたけど、
教科書から離れた内容が多かったのと、Seaserは
diとwebが結合しすぎてエンタープライズシステムには沿わない、
一枚岩すぎる、
サンドボックスが信用ならない、
Seaserとしての全体の思想がなく、開発者が勝手にやってる、
っという理由でspringに移行しました。
これが俺俺な部分なんですかね。
自己紹介みたいになりましたが。
何か外してますか？
100〜のスレッドの続きを読む
