- 1 名前：nobodyさん [2009/05/03(日) 18:02:12 ID:vXt2lE+8]
- 最近携わったプロジェクトのアーキテクチャは皆、トランザクションスクリプト。
SQLがわんさか書かれた後に、DBの変更が頻繁に行われるので、生産性が著しく下がる。
PofEAAで解説されているドメインモデルでどうして実装しないんだろう？
俺が身近な人に聞いた理由：
１．難解なモデリングをするイメージがあるから（アナリシスパターンのせいか？）
２．どうすれば実現できるかわからないから（アーキテクチャが複雑になるから？）
３．業務アプリにドメインモデルは向かないから（イベントドリブンではないから？）
４．Hibernate(EJB3)が重厚すぎてトラブルが起きたときに怖いから（フレームワークのノウハウがないから？）
５．画面毎に実装させないと作れないから（開発者がへぼいから？）
俺はHibernateを使わずにDAO＋リッチなORマッピング処理を自動生成する方法
（Ruby On RailsのActiveRecordみたいなかんじかな）で開発するのが好きで、
それを使ったプロジェクトでは実際に、生産性も保守性も高いと思うんだけど。。
どう思う？
- 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:???]
- それはそもそもトランザクションスクリプトと呼べるのか、と。
|
 |
