09/05/25 21:57:59 OuLK7/Hk
このように無限に関連を参照できる構造自体がドメインモデルではありませんが、必須なアーキテクチャです。
じゃあドメインモデルは何かというと、この無限に辿れる構造のModelクラスにビジネスロジックを実装したものです。
これで何が改善されるのかというと
・関連するデータを無限に辿れるため、画面の変更に強い。
・Modelクラス郡でカプセル化された中にビジネスロジックが記述できるため堅牢になる。
・Modelクラスを現実世界に近い状態で表現できる。
・画面毎にSQLを記述する量が減るため分業しやすい。
逆にデメリットとして
・アーキテクチャが複雑になる傾向がある。
・実際には完全なカプセル化は無理なので、ある程度開発ルールで縛る必要がある。
・単純に実装するとパフォーマンスが悪くなる。
・オブジェクト指向がわからない人にはModelクラスを全く設計も実装もできない。
21さんが言うように、現状、最後のデメリットが一番のネックで広まらないのかもね。。
28:nobodyさん
09/05/25 23:52:27 QpZDOw5B
>>26
少し論点が特定のものに行き過ぎてる。
Martin FowlerのGetterEradicatorという記事をご覧あれ。
29:22
09/05/26 00:38:57
>>23
取り敢えずAmazonでDDD注文してみた。英検準二級の俺じゃ辛そうだがw
>>1
分かりやすい例ありがと。
「蜘蛛の巣のような関連」の実際的な意味としてはそういうことなのか。
URLﾘﾝｸ(capsctrl.que.jp)
>>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
09/05/27 22:33:53 BGHGVumI
>>28
ご意見ありがとうございます。
GetterEradicatorを読んでみました。
26の説明がpublicなゲッターを用意しないとドメインモデルが構築できない
と誤解を招くということですね。ごめんなさい。
ところで、GetterEradicatorを読んでどうもしっくりきません。
ドメインモデルはビジネスロジックをOOPで実装することですから、カプセル化が
重要なこともわかります。ドメインロジックのメソッドだけが公開されるべきだと。
でも、実際にシステムを作ってみると、関連を辿って画面に表示するだけの
処理がかなりの割合を占めているし、更新処理でDaoに関連する情報を
公開する必要があるので、要件としても、アーキテクチャ的な制約としても
publicなゲッターを用意せざるをえないと思うのです。
31:nobodyさん
09/05/28 23:17:48 MDlOcl5d
>>30
Martin Fowlerを超えた思考ですね。
笑
32:nobodyさん
09/05/29 21:01:28 IrWAjTyc
>>30
いきなり制約から考えるより、まずはどうあるべきかを考える方がよいですよ。
日本人は、言語やフレームワークは使うものと思いがちですが、理想のためにはルールを変えてしまえばいいのです。
33:22
09/05/29 22:03:56
英語難しい。パンツのシートで空を飛ぶってなんだチクショウ。
34:1
09/05/30 03:01:31 JVbCJiZb
>>32
アドバイスありがとうございます。
確かに経験則にとらわれてしまうのはよくないですね。
カプセル化をするには、プレゼンテーション層向けのインターフェースを
用意して、それを使わせるルールにするのが一番簡単だと思いました。
>>33
あはは（＾＾；独特な言い回しが多いので理解するの難しいですね。
35:1
09/05/30 03:08:08 JVbCJiZb
>>34
自己レスです。
JSTLとかのTaglibはリフレクションしまくりで、インターフェースを
経由できないから結構穴が大きいですな。
36:1
09/05/30 03:17:46 JVbCJiZb
ドメインモデルにはJavaよりアクセス制御が柔軟な言語を
選ぶべきなのかな。。
37:nobodyさん
09/05/30 12:21:11 7CWJUI3D
>>1
まずは画面やデータベースを考えず、ドメインだけを考えた場合の理想的な形を考えてみたらどうですか？
38:nobodyさん
09/05/30 13:30:13
英語と日本語の壁が大きすぎるのだろうな・・・
ネイティブの人はいいな。
まじめに技術的プログラミングが出来て。
日本なんか、作業だからなｗ
何も考えちゃいない。
物が来た→処理。
39:1
09/05/31 13:48:40 ZKImC4BM
>>37
理想的な形というのは、
画面やアーキテクチャを無視して、理想的なドメインのモデリングをせよということですか？
それとも、ドメインモデルを中心にして考え直せば、理想的なアーキテクチャが導き出せるということですか？
40:nobodyさん
09/06/13 19:22:19 4WkC2nRl
Domain Driven Design（ドメイン駆動設計） Quickly 日本語版 記念上げ
URLﾘﾝｸ(www.infoq.com)
41:nobodyさん
09/09/06 11:48:09
ドメイン モデル パターンを使用する
URLﾘﾝｸ(msdn.microsoft.com)
42:nobodyさん
09/09/08 17:52:40
伸びないなー。
ネタ投下。
こないだ新規システムでアーキテクトやらせてもらえたから、ドメインモデルでやったんだ。
ASP.NET/C#2.0な構成。
俺は最初にコア部分作って後は別の人（外注）だったんだが、出来上がったもの見て落ち込んだ。
テストケースが空メソッドだらけな上にドメイン貧血症っていうかほとんどbean。
コーディングは各々の裁量に任せてたから、結局は俺の指示に不備があったんだと思うんだが、まぁそれはいいとして。
ドメインモデルで組まれたプロジェクトが上手く回った経験あるやついたら聞きたいんだが、末端のコーダーまでドメインモデルのなんたるかを知ってないとうまく回らんかな？
仮に知らなくてもいいって場合でも遵守させることとかあったら聞きたい。
43:nobodyさん
09/09/22 05:26:17
>>42 俺も興味あるんだけど、誰も答えられないのかな。
44:nobodyさん
09/09/26 14:06:38
海外のサイトとかプロジェクト見ていると
日本の平均的な技術者のレベルが低いなぁと常々思う。
45:nobodyさん
09/10/02 18:07:55
ウチの会社の社内SE兼PGは大体何を作らせても、
一カ所のプログラムのみが肥大化することが多い。
必要な業務処理に対して、
その全体を一つの関数なりメソッドなりに収めようとするから
いわゆるトランザクションスクリプト的な作りになっちゃうんだよね。
書く奴曰く、その方が見通しが良くて判りやすくシンプル、だそうな。
46:nobodyさん
09/10/05 14:38:23
>>45
機会があったら保守についてどう考えてるか聞いてみてくれ。
47:nobodyさん
09/10/23 21:45:11
それはそもそもトランザクションスクリプトと呼べるのか、と。