ドメインモデル VS トランザクションスクリプト

1 名前：nobodyさん [2009/05/03(日) 18:02:12 ID:vXt2lE+8] 最近携わったプロジェクトのアーキテクチャは皆、トランザクションスクリプト。 SQLがわんさか書かれた後に、DBの変更が頻繁に行われるので、生産性が著しく下がる。 PofEAAで解説されているドメインモデルでどうして実装しないんだろう？ 俺が身近な人に聞いた理由： １．難解なモデリングをするイメージがあるから（アナリシスパターンのせいか？） ２．どうすれば実現できるかわからないから（アーキテクチャが複雑になるから？） ３．業務アプリにドメインモデルは向かないから（イベントドリブンではないから？） ４．Hibernate(EJB3)が重厚すぎてトラブルが起きたときに怖いから（フレームワークのノウハウがないから？） ５．画面毎に実装させないと作れないから（開発者がへぼいから？） 俺はHibernateを使わずにDAO＋リッチなORマッピング処理を自動生成する方法 （Ruby On RailsのActiveRecordみたいなかんじかな）で開発するのが好きで、 それを使ったプロジェクトでは実際に、生産性も保守性も高いと思うんだけど。。 どう思う？ 23 名前：nobodyさん [2009/05/24(日) 22:14:36 ID:fimh7Ald] >>22 ドメインモデル貧血症の理解は入り口に過ぎず。 2chで理解しようってのは無理なんじゃ？ 24 名前：1 [2009/05/25(月) 21:34:23 ID:OuLK7/Hk] >>22 >EntityがLogicも包含すると。 アーキテクチャとしての違いの基本はそうです。つまりオブジェクト指向にするということです。 25 名前：1 [2009/05/25(月) 21:36:26 ID:OuLK7/Hk] 僕の理解では、アーキテクチャとしての大きな違いは、関連する情報の取得方法だと思います。 関連とは手続き型でいうと構造体に別の構造体の変数を持っている感じです。 手続き型であるトランザクションスクリプトでは、ServletやActionやServiceやLogicといった 処理専門のクラスがDaoを呼び出した結果を、この構造体にデータを詰め込みます。 当然ながら詰め込んでいない構造体のデータは参照しても値が取得できません。 例えば、Employee has Department has Companyという構造だとして、 処理専門のクラスがEmployeeとDepartmentしかデータを詰め込んでいない場合、 (Employeeのインスタンス)e.department.companyはnullになってしまいます。 26 名前：1 [2009/05/25(月) 21:37:14 ID:OuLK7/Hk] 一方、ドメインモデルも同じような構造をModelクラスで実装するのですが、 関連するModelインスタンスにデータを詰め込む処理は、Modelクラスの中に実装します。 例えば関連する情報を参照された際にModelクラスのゲッター内でDaoを呼び出します。 これにより関連する情報を無限に辿ることができるネットワークが構築できます。 例で言うと、処理専門のクラスがEmployeeのインスタンスを取得した後、 （Employeeのインスタンス）e.getDepartment().getCompany()を実行するだけで結果が取得できます。 27 名前：1 [2009/05/25(月) 21:57:59 ID:OuLK7/Hk] このように無限に関連を参照できる構造自体がドメインモデルではありませんが、必須なアーキテクチャです。 じゃあドメインモデルは何かというと、この無限に辿れる構造のModelクラスにビジネスロジックを実装したものです。 これで何が改善されるのかというと ・関連するデータを無限に辿れるため、画面の変更に強い。 ・Modelクラス郡でカプセル化された中にビジネスロジックが記述できるため堅牢になる。 ・Modelクラスを現実世界に近い状態で表現できる。 ・画面毎にSQLを記述する量が減るため分業しやすい。 逆にデメリットとして ・アーキテクチャが複雑になる傾向がある。 ・実際には完全なカプセル化は無理なので、ある程度開発ルールで縛る必要がある。 ・単純に実装するとパフォーマンスが悪くなる。 ・オブジェクト指向がわからない人にはModelクラスを全く設計も実装もできない。 21さんが言うように、現状、最後のデメリットが一番のネックで広まらないのかもね。。 28 名前：nobodyさん [2009/05/25(月) 23:52:27 ID:QpZDOw5B] >>26 少し論点が特定のものに行き過ぎてる。 Martin FowlerのGetterEradicatorという記事をご覧あれ。 29 名前：22 mailto:sage [2009/05/26(火) 00:38:57 ID:???] >>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のプロジェクトで下で実例みさてもらいたいもんだ。 30 名前：1 [2009/05/27(水) 22:33:53 ID:BGHGVumI] >>28 ご意見ありがとうございます。 GetterEradicatorを読んでみました。 26の説明がpublicなゲッターを用意しないとドメインモデルが構築できない と誤解を招くということですね。ごめんなさい。 ところで、GetterEradicatorを読んでどうもしっくりきません。 ドメインモデルはビジネスロジックをOOPで実装することですから、カプセル化が 重要なこともわかります。ドメインロジックのメソッドだけが公開されるべきだと。 でも、実際にシステムを作ってみると、関連を辿って画面に表示するだけの 処理がかなりの割合を占めているし、更新処理でDaoに関連する情報を 公開する必要があるので、要件としても、アーキテクチャ的な制約としても publicなゲッターを用意せざるをえないと思うのです。 31 名前：nobodyさん [2009/05/28(木) 23:17:48 ID:MDlOcl5d] >>30 Martin Fowlerを超えた思考ですね。 笑 32 名前：nobodyさん [2009/05/29(金) 21:01:28 ID:IrWAjTyc] >>30 いきなり制約から考えるより、まずはどうあるべきかを考える方がよいですよ。 日本人は、言語やフレームワークは使うものと思いがちですが、理想のためにはルールを変えてしまえばいいのです。 33 名前：22 mailto:sage [2009/05/29(金) 22:03:56 ID:???] 英語難しい。パンツのシートで空を飛ぶってなんだチクショウ。 34 名前：1 [2009/05/30(土) 03:01:31 ID:JVbCJiZb] >>32 アドバイスありがとうございます。 確かに経験則にとらわれてしまうのはよくないですね。 カプセル化をするには、プレゼンテーション層向けのインターフェースを 用意して、それを使わせるルールにするのが一番簡単だと思いました。 >>33 あはは（＾＾；独特な言い回しが多いので理解するの難しいですね。 35 名前：1 [2009/05/30(土) 03:08:08 ID:JVbCJiZb] >>34 自己レスです。 JSTLとかのTaglibはリフレクションしまくりで、インターフェースを 経由できないから結構穴が大きいですな。 36 名前：1 [2009/05/30(土) 03:17:46 ID:JVbCJiZb] ドメインモデルにはJavaよりアクセス制御が柔軟な言語を 選ぶべきなのかな。。 37 名前：nobodyさん [2009/05/30(土) 12:21:11 ID:7CWJUI3D] >>1 まずは画面やデータベースを考えず、ドメインだけを考えた場合の理想的な形を考えてみたらどうですか？ 38 名前：nobodyさん mailto:sage [2009/05/30(土) 13:30:13 ID:???] 英語と日本語の壁が大きすぎるのだろうな・・・ ネイティブの人はいいな。 まじめに技術的プログラミングが出来て。 日本なんか、作業だからなｗ 何も考えちゃいない。 物が来た→処理。 39 名前：1 [2009/05/31(日) 13:48:40 ID:ZKImC4BM] >>37 理想的な形というのは、 画面やアーキテクチャを無視して、理想的なドメインのモデリングをせよということですか？ それとも、ドメインモデルを中心にして考え直せば、理想的なアーキテクチャが導き出せるということですか？ 40 名前：nobodyさん [2009/06/13(土) 19:22:19 ID:4WkC2nRl] Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 記念上げ www.infoq.com/jp/minibooks/domain-driven-design-quickly 41 名前：nobodyさん mailto:age [2009/09/06(日) 11:48:09 ID:???] ドメイン モデル パターンを使用する msdn.microsoft.com/ja-jp/magazine/ee236415.aspx 42 名前：nobodyさん mailto:sage [2009/09/08(火) 17:52:40 ID:???] 伸びないなー。 ネタ投下。 こないだ新規システムでアーキテクトやらせてもらえたから、ドメインモデルでやったんだ。 ASP.NET/C#2.0な構成。 俺は最初にコア部分作って後は別の人（外注）だったんだが、出来上がったもの見て落ち込んだ。 テストケースが空メソッドだらけな上にドメイン貧血症っていうかほとんどbean。 コーディングは各々の裁量に任せてたから、結局は俺の指示に不備があったんだと思うんだが、まぁそれはいいとして。 ドメインモデルで組まれたプロジェクトが上手く回った経験あるやついたら聞きたいんだが、末端のコーダーまでドメインモデルのなんたるかを知ってないとうまく回らんかな？ 仮に知らなくてもいいって場合でも遵守させることとかあったら聞きたい。 43 名前：nobodyさん mailto:sage [2009/09/22(火) 05:26:17 ID:???] >>42 俺も興味あるんだけど、誰も答えられないのかな。 44 名前：nobodyさん mailto:sage [2009/09/26(土) 14:06:38 ID:???] 海外のサイトとかプロジェクト見ていると 日本の平均的な技術者のレベルが低いなぁと常々思う。 45 名前：nobodyさん mailto:sage [2009/10/02(金) 18:07:55 ID:???] ウチの会社の社内SE兼PGは大体何を作らせても、 一カ所のプログラムのみが肥大化することが多い。 必要な業務処理に対して、 その全体を一つの関数なりメソッドなりに収めようとするから いわゆるトランザクションスクリプト的な作りになっちゃうんだよね。 書く奴曰く、その方が見通しが良くて判りやすくシンプル、だそうな。 46 名前：nobodyさん mailto:sage [2009/10/05(月) 14:38:23 ID:???] >>45 機会があったら保守についてどう考えてるか聞いてみてくれ。 47 名前：nobodyさん mailto:sage [2009/10/23(金) 21:45:11 ID:???] それはそもそもトランザクションスクリプトと呼べるのか、と。

---

---

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef