国産DIコンテナSeasarとくーす その３
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNGってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
あと、開発プロセス「くーす」の話題もこちらでどうぞ。
本家 seasar.org
http://www.seasar.org/
Seasar Projectグループ
http://seasarproject.g.hatena.ne.jp/
ひがやすをのここだけの話
http://d.hatena.ne.jp/higayasuo/
前スレ
その１ http://pc5.2ch.net/test/read.cgi/tech/1092044210/
その２ http://pc5.2ch.net/test/read.cgi/tech/1098885253/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1077465099/
0210デフォルトの名無しさん
NGNG手続き型マンセー、Transaction Script上等って結論じゃなかったか？
0211デフォルトの名無しさん
NGNG0212デフォルトの名無しさん
NGNG0213デフォルトの名無しさん
NGNG給料計算は、給料計算担当者が。
0214デフォルトの名無しさん
NGNGAチーム、なつかしーなおい。
0215デフォルトの名無しさん
NGNG0216デフォルトの名無しさん
NGNG社員は
-自分の役職
-役職からの給与算出方法
のみを知っていれば「権限」などなくても給与計算できます。
よって給与計算担当者は必要ありません。
もちろん、コンテキストによっては給与計算担当者が必要になることがあるかもしれないことは否定しませんが。
0217デフォルトの名無しさん
NGNGで、社員ひとりひとりに自分で給与計算させる会社があるの？
モデリングとは話が違うかもしれんけど、社員を渡せば給料が返ってくる、給与計算者がいるほうがいいと思うなぁ。
0218デフォルトの名無しさん
NGNGこの前提がそもそも非現実的で意味無し。
0219デフォルトの名無しさん
NGNGサンプルコードに何を求めてるんだろう?
0220デフォルトの名無しさん
NGNGあした使えるコード。
あさって納品できるコード。
0221デフォルトの名無しさん
NGNG「社員が持つべきケースのサンプル」
と、「計算担当者が持つべきケースのサンプル」があるだけ。
0222デフォルトの名無しさん
NGNG0223デフォルトの名無しさん
NGNGそいつのせいでスレ違いな書き込みばかりになってるじゃないか！
0224デフォルトの名無しさん
NGNGログ見ても、ナイーブがどうこうとか、某blogのアイドル写真がそろそろ邪魔くさいとか、あまりスレタイとは関係ないし。
0225デフォルトの名無しさん
NGNGどうやらファウラーらしい
0226デフォルトの名無しさん
NGNG> 正解がないだけに色々と人によってまちまちになっちゃうから
> いっその事統一ルールで、データの振る舞いは
> 全部分けちゃえって話だと読みましたがどうでしょう。
に賛成。
債務とか責任とかを考えて適切な場所に処理を記述とか考えていくと、いろいろなところにコードが分散してしまって、追えなくなってしまう。
DBのViewとかトリガーとかまで考えて適切な場所に処理を記述していくと、もう、どうしようもなくなる。
0227デフォルトの名無しさん
NGNG維持すべき設計文書を書いてないだけじゃないかな。
0228デフォルトの名無しさん
NGNGしかも、設計文書とJavaソースとViewやトリガは、見るためのツールが違うので、煩雑に。
それだけ追うための手間が増えるわけですよ。
修正の場合も、設計文書を必ず修正する必要があって、この作業は徹底するのにかなりの労力を伴う。
単純に比較すれば、一ヶ所で記述した場合にくらべて、労力自体は増えると思うのですよ。
とくに、設計文書管理の労力。
0229デフォルトの名無しさん
NGNG実際には、問題になるのは、レベルではなくて、考え方で。
むしろレベルが高い、考え方の違う人が書いたシステムが非常に追いにくくなるわけで。
システムを追う前に、どのような考え方で書かれたのかをプロファイリングしないといけない。
0230デフォルトの名無しさん
NGNGアプリケーション独自のロジックに関しては、ドキュメントがなくてもわかるようなものが理想で。
ただし、アプリケーションの骨格がドキュメントに依存するのは仕方がないと思う。
でも、アプリケーションの骨格は、揺るぎにくく共通化しやすいから、その部分をみんなで使えるようにしましょう、と。
で、そのアプリケーションの骨格のドキュメントが、くーすなのかなぁと思う。
0231デフォルトの名無しさん
NGNG0232デフォルトの名無しさん
NGNG> に賛成。
> 債務とか責任とかを考えて適切な場所に処理を記述とか考えていくと、いろいろなところにコードが分散してしまって、追えなくなってしまう。
> DBのViewとかトリガーとかまで考えて適切な場所に処理を記述していくと、もう、どうしようもなくなる。
債務(さいむ)じゃなくて責務(せきむ)な。
0233デフォルトの名無しさん
NGNG恥ずかしげも無くよく言えるな、おい。
ＸＰｅｒもどきの増殖にも困ったもんだ。
0234デフォルトの名無しさん
NGNG数度の変更を経たにもかかわらず、ちゃんと同期しているドキュメントをみたことがない。
0235デフォルトの名無しさん
NGNG0236デフォルトの名無しさん
NGNGうらやましいな。
0237デフォルトの名無しさん
NGNG0238デフォルトの名無しさん
NGNG先ず書く、そして打つという手順を守りさえすればそんなはずはない
と上司は言うけれど・・・・・・・・
短期で動くモノを差し出せとせっつかれて、それどころじゃないのです。
アジャイルって本当に素晴らしいモノなのかな？なんか週間連載を
抱えた漫画家みたいって言うか、納期が短い間隔で何回もやってく
る感じで、昔よりも寧ろ過酷になってる様な気がするんですが・・・・・
0239デフォルトの名無しさん
NGNG0240デフォルトの名無しさん
NGNG変更管理をきっちりすれば同期問題はおきないぞ。
0241デフォルトの名無しさん
NGNGだから、変更管理をきっちりしてる
プロジェクトで仕事した事がない、って話なんです。
ちっこい案件は別だけど。
0242デフォルトの名無しさん
NGNGＰＭがマヌケということか。同情するよ。
まぁ、悲観するな。そのうちまともなＰＲＪに出会えるから。
0243デフォルトの名無しさん
NGNG構成管理をきっちりしないと、同期問題がおきるってことでしょ。
で、構成管理をきっちりすることは、組織的な成熟度が高くないといけない。
適用しやすい開発方法論を考えるのなら、
「こうやればうまく開発できます。でもドキュメントが大切なので、構成管理はきっちりやってください」
というものはどうかと思う。
構成管理がきっちりできるなら、他の能力も高いことが多いから、どうとでもやってくれという感じ。
0244デフォルトの名無しさん
NGNG. |（･∀･）|
. |￣￣￣ ｼﾞｻｸｼﾞｴﾝ王国
△
△ｌ |
＿＿△|_.田 |△＿＿＿＿＿
|__|__門_|__|＿＿＿＿＿|＿＿＿＿＿
0245デフォルトの名無しさん
NGNGTheBlobを避けるためにPoltergeistに向かっているように思うなー。
The Blob
http://www.antipatterns.com/briefing/sld024.htm
Poltergeist
http://www.antipatterns.com/briefing/sld030.htm
0246デフォルトの名無しさん
NGNGだからフレームワークは無用
プログラミングしよう
0247デフォルトの名無しさん
NGNGまぁ、わからないでもないよ。最近は知ったかぶりのアジャイル莫迦が多すぎるからな。
JAVAWORLDも酷い記事を書くやつが増えたが、編集は何をやっているんだか。
0248デフォルトの名無しさん
NGNG0249デフォルトの名無しさん
NGNG使い捨てで、ソースコードとの同期はやらないんだよね。
0250デフォルトの名無しさん
NGNG捨てはロバストネス図じゃなかったっけ？
0251デフォルトの名無しさん
NGNG捨てはロバストネス図じゃなかったっけ？
0252デフォルトの名無しさん
NGNGあれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
0253243
NGNGもちろん適切に使えばよいけど、一度乱用する時期を経ないと適切に使えないと思う。
プロジェクトの発言権を持った人の中に乱用する時期の人がいる可能性も高い。
0254243
NGNG「ドメインモデルは、複雑なコードを整理しやすいのがメリットだ。
ただ、開発者にとって理解しにくく、またRDBMSとのマッピングが複雑になる。
そこで、ORマッピングレイヤを設けなくてはならない。
そのため、ドメインロジックがシンプルな場合は、トランザクションスクリプトを採用した方がいい。」
ということだ。やっぱファウラータンは俺のために言葉を用意してくれてて偉いな。
ttp://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html
0255デフォルトの名無しさん
NGNGそんな考えはレガシーで、ドメインモデルは複雑な
ロジックを記述するには向かない
という考えってどうよというのが先週からの話。
少しは流れを嫁。
0256デフォルトの名無しさん
NGNGつまり、すごく複雑ならドメインモデルでちょっと複雑ならトランザクションスクリプトっていってるのを、すごく複雑でもトランザクションスクリプトでってこと？
0257デフォルトの名無しさん
NGNG0258デフォルトの名無しさん
NGNGこの辺かな。
http://d.hatena.ne.jp/higayasuo/20041223#1103771319
1週間くらい前からいろいろもとねたがある。
0259デフォルトの名無しさん
NGNG0260デフォルトの名無しさん
NGNG> ２．1を再帰的に繰り返す。
構造化じゃん。
0261デフォルトの名無しさん
NGNGメソッド分割なのかコンポーネント分割なのかという話だと思うよ。
ちなみにそれが構造化ならあらゆる処理がが構造化。
自分で処理するか他人に任せるしかないんだから。
0262デフォルトの名無しさん
NGNGでも、トランザクションスクリプトじゃない、って書いてある。
ここに書いてあるのは、トランザクションスクリプトを構造化したらいいって話だよね？
そしたら、コマンドパターンっぽく切り替えやすくなると。
構造化って、おおざっぱなものが細かいものを再帰的に内包するモデルのことだよね？
違うの？
0263デフォルトの名無しさん
NGNGで、Javaだと、ひとつの処理をひとつのオブジェクトに割り当てるといろいろ切り替えれて便利、っていう話だと思ったんだけど。
0264デフォルトの名無しさん
NGNGってことで、オブジェクトに持って切り替えれるようにしましょうってことでしょ？
切り替える用途やら規模によって、ストラテジーだとかコマンドとかステートとか、いろいろパターン名が変わるだけで。
0265デフォルトの名無しさん
NGNGたぶん、構造化というよりは、自分の役割だけをこなしてあとは、
人に任せるということなんだと思う。
ドメインモデルは、1つのクラスに役割が集中しすぎる危険性があるという話。
0266デフォルトの名無しさん
NGNG言い方が違うだけで、構造化とやってることは同じだと思うけど。
人=オブジェクトって考えが出てるけど、これはJavaの言語仕様上オブジェクトが便利なだけで。
関数ポインタが使えるか、メソッドを代入できる言語では、オブジェクトである必要はなさそうだし。
そのオブジェクトはステートレスなんだよね？
つまりは、ドメインモデルを適切に構築するのは難しいから、構造化されたトランザクションスクリプトで、ってことでしょ？
0267デフォルトの名無しさん
NGNGただ、ここでインターフェイスを持ち出してくる必要があるのかないのか。
インターフェイスはテストの都合で必要なわけで。
処理を動的に切り替える予定がない部分をインターフェイスにする理由は、それしかないよね？
0268デフォルトの名無しさん
NGNG0269デフォルトの名無しさん
NGNG「モデル」部分を「単純なデータ保持／DBアクセスオブジェクト」として完全委譲した
だけで、これはドメインオブジェクトだって理解した方がいいんじゃないの？
トランザクションスクリプトってのは、サービス層でDBアクセスも全部世話して、呼び出した
メソッド一つで全部やってしまうようなもんだろ。
プレゼンテーション層 -> サービス層（薄い） -> ドメインモデル（モデルを基準に分割／ORマッピングもする） ->DB
が
プレゼンテーション層 -> サービス層（薄い） -> ドメインオブジェクト（サービスを基準に分割） -> 薄いモデル（ほぼORマッピングだけする） -> DB
になっただけなんじゃないの？ どっちみちサービスの連鎖の開始ポイントとして、Facade的な
薄いサービス層は現れてしまうし。
で、薄いモデル部分がドメインモデルと比べて明らかな貧血症だから騒いでるだけだろ。
俺にはデータアクセスをドメインモデルから外に出して、分割の基準を変えたように見える。
0270デフォルトの名無しさん
NGNG結局サービス層のことをドメインと呼んで、その前に置いたコントローラー的な層をサービス層と呼んでるんじゃない？
で、実際にドメインになる部分が薄くなって、「ドメインモデル貧血症」になってるからどうこう言ってるんじゃないの？
いや、よくわからんのだけど。
0271デフォルトの名無しさん
NGNG0272デフォルトの名無しさん
NGNG学生ですか？
機能拡張とか仕様変更とか、手作業でトランザクション制御する手間とか
納期とか考えたことある？
0273デフォルトの名無しさん
NGNG> メソッド一つで全部やってしまうようなもんだろ。
いや、ドメインモデルを構築する代わりに全部１つの流れでやりましょうっていう形。
だから、ドメインモデルと置き換わるはず。
で、もちろん１つのメソッド・ひとつのオブジェクトで完結する必要はないと思う。
サービス層は、適切なトランザクションスクリプトを呼び出す層ということになるんじゃない？
0274デフォルトの名無しさん
NGNG> 手作業でトランザクション制御する手間
トランザクションが必要で、それがAOPで実現されてるならインターフェイスを使うしかないね。
で、機能拡張とか仕様変更とかの話だと、ソース追う手間が増えることを考えると、一概に言えるのかなぁ。
ソース追う手間は、無視してしまえる程度にしか増えないものなの？
0275デフォルトの名無しさん
NGNGいままでのクラスと同じ名前でインターフェイス作れば、ソースは変更しなくていいし、オブジェクトの生成はDIでやってるわけだからそこ書き換えるだけじゃないかなぁと。
0276デフォルトの名無しさん
NGNGこれなんか読んでると、別にトランザクション・スクリプトでもいいじゃん、という気になる。
おれ、ドメインモデルってモデル間が密結合しすぎのような気がするんだけど。
0277デフォルトの名無しさん
NGNG0279デフォルトの名無しさん
NGNG複雑な業務ロジックだと、トランザクションスクリプトには
向かないというのはなぜ?
別にトランザクションスクリプトはどうでもいいんだけど、
コンポーネント分割でDIで組み立てるやり方なら、
逆に複雑な業務ロジックに向いてると思うけど、
理由は、それぞれのコンポーネントは小さいから。
ドメインモデルは、複雑なロジックになればなるほど、
クラスは大きくなる。
0280デフォルトの名無しさん
NGNG複雑な業務ロジックをやる予定は、今しばらくないので、「ファウラータンが言ってるから」で済ませてるんだけど、だめ？
なにか説明するにしても、ファウラーの言葉の引用になりそう。
とりあえず、ドメインモデルとトランザクションスクリプトの違いは、オブジェクトが状態を持つか持たないかだと思うけど。
で、複雑な業務ロジックの場合は、オブジェクトが状態を持ったほうが好都合なんじゃないのかなぁ。
0281デフォルトの名無しさん
NGNG0282デフォルトの名無しさん
NGNG複雑なロジックを単純な役割に分割してそれぞれの役割にコンポーネントを
割り振るからだろう。
それぞれの役割は単機能だから小さい。
ドメインモデルだとデータに対して振る舞いを割り当てるから、
複雑になればなるほど、やらなければならない役割が増える。
0283デフォルトの名無しさん
NGNG> >>279
> 複雑な業務ロジックをやる予定は、今しばらくないので、「ファウラータンが言ってるから」で済ませてるんだけど、だめ？
> なにか説明するにしても、ファウラーの言葉の引用になりそう。
引用は別に良いと思うけど、理由を説明できなければ意味はない。
ファウラーたんも盲目的に信じて欲しいとは思ってないと思うけど。
> とりあえず、ドメインモデルとトランザクションスクリプトの違いは、オブジェクトが状態を持つか持たないかだと思うけど。
そんなことどっかに書いてある?
0284デフォルトの名無しさん
NGNG0285デフォルトの名無しさん
NGNG> そんなことどっかに書いてある?
そうじゃないの？
0286デフォルトの名無しさん
NGNG>>282に書いてあるじゃん。分割単位が役割じゃなくてモデルだからだろ。
0287デフォルトの名無しさん
NGNG0288デフォルトの名無しさん
NGNG0289デフォルトの名無しさん
NGNGトランザクションスクリプトはいくらでも分割できるだろうけど、そのとき大きなドメインのモデルよりいいかどうかは疑問に思える。
杞憂なのかな？
0290デフォルトの名無しさん
NGNGORマッピングで、１つのテーブルをいくつかのオブジェクトにマッピングできるものもあるわけだし。
0291デフォルトの名無しさん
NGNGいいたいのか、大して変わんないんだからドメインモデルでいいじゃんといいたいのか、
言ってることに利点など何もない、問題は存在しないといいたいのか。
0292デフォルトの名無しさん
NGNGデマルコの「構造化分析とシステム仕様」は、「構造化」の原典のひとつだと思って引っ張ってきたんだけど、違ってる？
0293デフォルトの名無しさん
NGNG分割統治せよは、昔から言われている真実。
大きいより小さいほうが中身がわかりやすいのは当たり前。
複雑なドメインロジックの場合、データと役割は単位(大きさ)が
かみ合わないことのほうが多いので適切に分割できない。
たいていの場合、1つのデータに多くの役割が集中する。
なぜかっていうとそのデータに関する役割を集めるからね。
必然的にそうなる。
0294デフォルトの名無しさん
NGNGドメインモデルが分割できないときに、細切れのトランザクションスクリプトをばらまいても、問題を複雑にするだけということはないだろうか？と。
0295デフォルトの名無しさん
NGNG考えるからさ、「この機能、どこにおいてもぴったりしない」とかいうことがあるよねえ。
で「社員Util」とか変なのがいつのまにか作られてたり。
俺はサービスを分割基準に置くのは悪い考えではないと思うし、それによってオブジェクト指向的な
利点を無効にしてしまうこともないと思うよ。
モデルの役割をモデル内データの管理とその永続化だけにしようって考え方も、とてもオブジェクト
指向的だとおもうけど。
0296デフォルトの名無しさん
NGNGんん？ 単にモデルにはモデルの役割だけさせて、ビジネスロジックはモデルの役割じゃないから
サービスとして分割しようって言ってるだけだと思うんだけど。
サービスとして分割してしまえば、分割の自由度は上がる。でも意味もなく細切れにしたら混乱する
のはあたりまえ。「ここは分割しなきゃ」と思ったときに、ドメインモデルだと分割しにくいけども、
サービスだけならきれいに分割できることがあるってだけ。
0297デフォルトの名無しさん
NGNG間違ってないよ。
なんか構造化は悪いものだとか、オブジェクト指向とはかみ合わないとか
勘違いしているやつが多いのか。
0298デフォルトの名無しさん
NGNG実際、ここにはドメインモデルがいいとは書いてあるけど、トランザクションスクリプトがダメな理由は書いてないね。
だから、どっちも疑問といえば疑問なんだけど。
ただ、モデル化は視点の問題だと思ってるので、片方のモデルで適切に分割できないのに片方のモデルでは適切に分割できる、というのが、にわかに信じれない。
複雑なものを細切れにすると、単純なものが複雑に散らばるだけなんじゃないかと。
それよりは、大きな複雑なものがあったほうが、見通しも良くていいんじゃないかと思うわけです。
そのとき、それぞれの部品の単純さを主張しても、意味のある主張になるのかなぁと。
実際に上記のサイトのグラフで線が入れ替わるところのような複雑なものは、単純に例示できないだろうから、難しい話だとは思うんだけど。
0299デフォルトの名無しさん
NGNGそう。
だから、なんでヒガさんが構造化だと言われたことを誤解だと斬って捨ててるのか、疑問。
0300デフォルトの名無しさん
NGNG適切って言葉をどう捉えるか。くーす的なのは「いかに維持しやすいか」が視点だろう。
そのかわりドメインモデルの明快な美しさは失われるが、それはビジネスだから諦める。
理屈ではドメインモデルってみんな好きなんだよ。でも仕事で使ってみると
世の中明快に割り切れるものなんてないし、たとえうまく設計できたとしても
システムは完成した瞬間から陳腐化するから維持運営に結構苦労する。
サービス分割って考えは希望が持てる。業務とコードが対応してるから直すときに躊躇がいらない。
将来一部業務に大変更が発生しても、ほかへの影響なしにそこだけ手を入れられるってのはステキだ。
0301デフォルトの名無しさん
NGNGそれはそれでかまわないと思ってる。でも実際には、そのモデルＡの役割というよりは、モデルＡ
とBとCをつかってほにゃららする、という機能が結構あるんだよ。
結果としてＡがB、Cを保持したりして実現するわけだ。
それがＡというモデルの機能なのか？という疑問というのが１点ある。B、Cでないとどうして
いえるのか？ またＡでもBでもCでもなく、ＡＢＣと取りまとめる別のモデルの機能ではないか？
さらに、その機能のためにＡはB、Cを保持してるわけで、結局は「複雑に散らばってる」わけだ。
大きな複雑なモデルってのは、「大きなものがひとつあって、そこだけ見ればなんとかなる」んじゃ
なくて、細切れのモデルが一つのモデルの中で絡み合ってごちゃごちゃになってて、結局全部の
モデルを理解していないと「大きな複雑なモデル」を理解できない。だから「ドメインモデルは全体を
理解してないと使えない」と言われるわけ。さらにモデルが永続化も担うので、役割過剰と言われ
ても仕方がないと思う。
サービス分割も同じ問題ははらんでるよ（あるサービスが別のサービスと絡み合うとかね）。
ただサービスが一つのビジネスロジック上の役割で分割されているので、触るときに影響範囲が
見えやすいし、「あ、これは別の業務だな」と思ったら躊躇なく分割できる。結果として細切れの
サービスができかねないのは事実なんだけど、細切れのものが業務単位でまとまってるので、
多少はまし、といったところか。
0302デフォルトの名無しさん
NGNG0303デフォルトの名無しさん
NGNGとりあえず前提条件おさらい。
どうやって計ったかはしらないけど、トランザクションスクリプトだと天井つきぬけるくらいコストがかかるとファウラーが主張するくらいビジネスロジックが複雑なときの話。
で大きいまま分割できないドメインのモデルがある。
そのとき、そのドメインのモデルは、その大きさのままが維持しやすいことになるんじゃないのかなぁ。
将来そのモデルのかかわる一部業務に大変更が発生しても、いろいろなところを追わずに、そのモデルだけ修正すれば済むわけで。
もちろん、分割できないモデルだから、そのモデル全般に影響が及んでるだろうけど。
縁がありそうな程度の複雑さのビジネスロジックでは、>>300に賛成。
0304デフォルトの名無しさん
NGNGうーん、なんか逆な気がするな。
大きく複雑なモデルは仕事をいろんなモデルに移譲しまくってるので、「業務」単位でみると、
一つの業務追加・変更で複数のモデルに影響がでるよ。
モデルの分割単位はあくまで「なんらかのビジネス上の概念」であって、業務ではないからね。
で、たいていの業務では、「なんらかのビジネス上の概念」が複数絡まってるもんだ。この複数
絡まってる機能をどこにおく？という話じゃないか。
0305デフォルトの名無しさん
NGNGいや、そのとき、ドメインモデルだと細切れのモデルが絡み合っててごちゃごちゃになってて結局全部のモデルを理解してないくらい複雑なのに、サービス分割だと影響範囲が見えやすく業務単位でまとまってるってことはないんじゃないのかな、と。
サービスを、躊躇なく分割したり業務単位でまとめれるなら、ドメインモデルも同じように分割して業務単位でまとめれる可能性が高いんじゃなかろうか。
0306デフォルトの名無しさん
NGNGもちろん、複雑じゃない業務ロジックの話で、ドメインモデルよりサービスでの分割がいいというのは、同意できる。
0307デフォルトの名無しさん
NGNGそうだね。でもそのようにドメインモデルを分割したら、それはドメインモデルじゃないんじゃない？
ドメインモデルはそのモノが担うべきものだけを提供すべきで、業務的な必要性から関係ない機能を
追加するもんじゃないからさ。理想としては、もし業務要件が複数のモデルが絡み合うものなら、
複数のモデルを直すべきなんだよね。
業務要件で勝手にまとめてどっかのモデルに押し込んじゃったりしたら、ドメインモデル特有のオブジェ
クト指向的美しさは台無しじゃないか？ でもビジネスはそんな美しさは関係ない訳で、そこに軋轢があ
るんじゃないか。
サービスだと、そもそも業務単位でまとめるもんなんだし、分割しやすいしまとめやすいってことじゃ
ないかと。まあ業務要件があって仕事があるという現実に即した分割方法じゃないかな？
0308デフォルトの名無しさん
NGNGまずどういうシステムを対象にどのように測定したのか知りたい。
同じシステムをそれぞれのパタンで作って比較したのか、
それとも色んなシステムを比較したのか。どこかにどのように
調査したのか書いてるのある？
0309デフォルトの名無しさん
NGNGその意見が、非常に複雑な業務ロジックで成り立つのかが疑問なんです。
まあ、その解を得ることに、「>>308の図が読み解ける」という以上の意味はないんだけど。
というか、ファウラーが>>308の図のそれぞれの軸をどう計ったかが一番疑問だな。
もちろん長い年月ソフトウェアに関わって、いろいろな開発をみてきて、実際の測定もしてきたわけだから、それなりの根拠があることは間違いないんだけど。
■ このスレッドは過去ログ倉庫に格納されています