トップページ⇒tech
1001コメント376KB

国産DIコンテナSeasarとくーす その３

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ？みんなもう使ってるの？
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。

あと、開発プロセス「くーす」の話題もこちらでどうぞ。


本家 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/
0192デフォルトの名無しさんNGNG
>もしそうじゃなかったとしたら、172の2の反論自体無効だね。
>だって、おれは複数のロールを持つクラスをロールごとに分割することには賛成なんだもん。

calculatePayとisExpiredはひとつのロール？
おれはどう考えても別々のロールだと思うんだけど。

019344NGNG
>>192
> calculatePayとisExpiredはひとつのロール？
> おれはどう考えても別々のロールだと思うんだけど。

コンテキストによる。
0194デフォルトの名無しさんNGNG
おれはインスタンス変数だけで処理が完結するなら、その動作は該当クラスに乗せても
いいと思う。

あくまでモデルの話だけどさ。
0195デフォルトの名無しさんNGNG
>>193
じゃそんな例出すなよ。コンテキストによるなんていわれたら議論のしようがない。
おれはcalculatePayとisExpiredがひとつのロールになるコンテキストなんて現実にはほとんどありえないと思うが。
0196デフォルトの名無しさんNGNG
それに
>>147で
>この場合のオブジェクトＺは単一責任の原則をやぶってると思う?
>おれは思わないよ。
ていってるのはなんなんだ？これを見たら普通44はcalculatePayとisExpiredがひとつのロール
だと考えてると思うんじゃない？
0197デフォルトの名無しさんNGNG
役職はStateパターンにして、社員にくっつければ？
0198デフォルトの名無しさんNGNG
> 役職はStateパターンにして、社員にくっつければ？
なんでも適当に言えばいいってもんじゃないぞ
0199デフォルトの名無しさんNGNG
>>198
いや、そんなに悪くないんじゃない?
俺の場合、役職に関する処理が増えた場合はそれを採用するかも。
0200197NGNG
昇進したら役職Stateを取り替えるだけ。
ある役職の処理が変わっても、社員や他の役職のソース修正しなくて済む。
けっこう良かったですよ。
0201デフォルトの名無しさんNGNG
>>200
役職や職責でstateパターンってまだ試した事無いんだけど
どうも永続化が、って逆か、DBから読み込んで
Entityを生成する時が面倒な気が、ぼんやりとするんです。
どうでした？俺が判ってないだけかなー。
0202デフォルトの名無しさんNGNG
役職は状態遷移じゃないだろう。このスレ大丈夫か？

0203デフォルトの名無しさんNGNG
現実世界では役職と状態遷移は違うものでしょうけども
197の提案は、同じ設計パターンが使えませんかねって話なので
202は反論になってないです。

ファウラーに、在庫推移は複式簿記で管理しないだろ、大丈夫かお前？
といってるようなもんじゃないでしょうか。

もうちょっとダメな理由を詳しくよろしく。
0204デフォルトの名無しさんNGNG
>>202
デザインパターンはマニュアル思考しかできない人間を生産してしまう
などというトンチキな批判がうまれる原因ｗ
0205デフォルトの名無しさんNGNG
>>203
処理中心になってしまうかもしれないけど、考え方としてはStrategyパターンで行ったほうが素直なのではないでしょうか？
やっぱり、役職は状態ではないと思う。
話が戻ってしまうかもしれないが・・
0206デフォルトの名無しさんNGNG
>>201
Hibernateにおまかせ。
0207デフォルトの名無しさんNGNG
状態は列挙のうち一つしかもてない。役職は複数もてる（もしくは持たない）ことが一般的。


役職はロール（というオブジェクト）の一種。
組織の規程は、ロールに対して責務を割り当てる。けして個人や部署じゃない。これはビジネスルール。
個人や部署はパーティとしてまとめられる。
パーティはN個のロールを持てる。
組織の規程は、パーティへのロールの割り当て方について制約を課す。これもビジネスルール。
0208デフォルトの名無しさんNGNG
ＧＯＦとかちゃんと読んでるのか、おまえら
0209デフォルトの名無しさんNGNG
ＤＩとかくーすに話を戻しましょう。
0210デフォルトの名無しさんNGNG
なんで？　もう語ることないじゃん。
手続き型マンセー、Transaction Script上等って結論じゃなかったか？
0211デフォルトの名無しさんNGNG
でもSQLだけは勘弁な
0212デフォルトの名無しさんNGNG
エンティティの責任は、データを保持することなので、それ以上の責任を押し付けてはいけません。
0213デフォルトの名無しさんNGNG
給料が社員によって決まるとしても、社員には給料を決める権限などないのです。
給料計算は、給料計算担当者が。
0214デフォルトの名無しさんNGNG
>>211
Aチーム、なつかしーなおい。
0215デフォルトの名無しさんNGNG
>211はコング
0216デフォルトの名無しさんNGNG
>>213
社員は
-自分の役職
-役職からの給与算出方法
のみを知っていれば「権限」などなくても給与計算できます。
よって給与計算担当者は必要ありません。

もちろん、コンテキストによっては給与計算担当者が必要になることがあるかもしれないことは否定しませんが。
0217デフォルトの名無しさんNGNG
>>216
で、社員ひとりひとりに自分で給与計算させる会社があるの？
モデリングとは話が違うかもしれんけど、社員を渡せば給料が返ってくる、給与計算者がいるほうがいいと思うなぁ。
0218デフォルトの名無しさんNGNG
＞「社員の給与は社員の役職によってのみ決まる」

この前提がそもそも非現実的で意味無し。
0219デフォルトの名無しさんNGNG
>>218
サンプルコードに何を求めてるんだろう?
0220デフォルトの名無しさんNGNG
現実的なコードじゃない？
あした使えるコード。
あさって納品できるコード。
0221デフォルトの名無しさんNGNG
サンプルコードに関して、>>216-217のような話は無意味では。
「社員が持つべきケースのサンプル」
と、「計算担当者が持つべきケースのサンプル」があるだけ。
0222デフォルトの名無しさんNGNG
で、社員が持つべきケースなんてほとんどないから、意味がないというかサンプルとして有害じゃないの？
0223デフォルトの名無しさんNGNG
だれが、社員と給与で例を示したんだ？
そいつのせいでスレ違いな書き込みばかりになってるじゃないか！
0224デフォルトの名無しさんNGNG
Seasarもくーすも、話題にするような目立った動きないから、いいんじゃない？
ログ見ても、ナイーブがどうこうとか、某blogのアイドル写真がそろそろ邪魔くさいとか、あまりスレタイとは関係ないし。
0225デフォルトの名無しさんNGNG
>>223
どうやらファウラーらしい
0226デフォルトの名無しさんNGNG
>>156の
> 正解がないだけに色々と人によってまちまちになっちゃうから
> いっその事統一ルールで、データの振る舞いは
> 全部分けちゃえって話だと読みましたがどうでしょう。

に賛成。
債務とか責任とかを考えて適切な場所に処理を記述とか考えていくと、いろいろなところにコードが分散してしまって、追えなくなってしまう。
DBのViewとかトリガーとかまで考えて適切な場所に処理を記述していくと、もう、どうしようもなくなる。
0227デフォルトの名無しさんNGNG
View やトリガーがあると追えない？
維持すべき設計文書を書いてないだけじゃないかな。
0228デフォルトの名無しさんNGNG
そうすると、一ヶ所に処理を記述したときには、そのソースだけを見ればよかったのが、設計文書とViewなりトリガーなりとJavaのソースと、いろいろなところを見ないといけなくなるわけですね。
しかも、設計文書とJavaソースとViewやトリガは、見るためのツールが違うので、煩雑に。
それだけ追うための手間が増えるわけですよ。

修正の場合も、設計文書を必ず修正する必要があって、この作業は徹底するのにかなりの労力を伴う。
単純に比較すれば、一ヶ所で記述した場合にくらべて、労力自体は増えると思うのですよ。
とくに、設計文書管理の労力。
0229デフォルトの名無しさんNGNG
で、問題はくーすでたびたび話題になってる、作業に関わる人のレベルが一定ではないということですね。
実際には、問題になるのは、レベルではなくて、考え方で。
むしろレベルが高い、考え方の違う人が書いたシステムが非常に追いにくくなるわけで。
システムを追う前に、どのような考え方で書かれたのかをプロファイリングしないといけない。
0230デフォルトの名無しさんNGNG
ドキュメントは非常に儚いので、アプリケーションの枝葉がドキュメントに依存するのは、問題があるんじゃないかと。
アプリケーション独自のロジックに関しては、ドキュメントがなくてもわかるようなものが理想で。

ただし、アプリケーションの骨格がドキュメントに依存するのは仕方がないと思う。
でも、アプリケーションの骨格は、揺るぎにくく共通化しやすいから、その部分をみんなで使えるようにしましょう、と。
で、そのアプリケーションの骨格のドキュメントが、くーすなのかなぁと思う。
0231デフォルトの名無しさんNGNG
シンプルなオブジェクトを複雑に組み合わせるのと、複雑なオブジェクトをシンプルに組み合わせるのと、どっちがいいんだろう？
0232デフォルトの名無しさんNGNG
>>226
> に賛成。
> 債務とか責任とかを考えて適切な場所に処理を記述とか考えていくと、いろいろなところにコードが分散してしまって、追えなくなってしまう。
> DBのViewとかトリガーとかまで考えて適切な場所に処理を記述していくと、もう、どうしようもなくなる。

債務(さいむ)じゃなくて責務(せきむ)な。
0233デフォルトの名無しさんNGNG
ドキュメントが儚い？
恥ずかしげも無くよく言えるな、おい。
ＸＰｅｒもどきの増殖にも困ったもんだ。
0234デフォルトの名無しさんNGNG
>>233
数度の変更を経たにもかかわらず、ちゃんと同期しているドキュメントをみたことがない。
0235デフォルトの名無しさんNGNG
俺も無い

0236デフォルトの名無しさんNGNG
233は、よほど躾の行き届いた組織にいるらしい。
うらやましいな。
0237デフォルトの名無しさんNGNG
ActionFormにインジェクションできますか？
0238デフォルトの名無しさんNGNG
見た事がないというか、出来た事がない＿|￣|○|||
先ず書く、そして打つという手順を守りさえすればそんなはずはない
と上司は言うけれど・・・・・・・・
短期で動くモノを差し出せとせっつかれて、それどころじゃないのです。

アジャイルって本当に素晴らしいモノなのかな？なんか週間連載を
抱えた漫画家みたいって言うか、納期が短い間隔で何回もやってく
る感じで、昔よりも寧ろ過酷になってる様な気がするんですが・・・・・
0239デフォルトの名無しさんNGNG
ここはサンデープログラマのスレですか？
0240デフォルトの名無しさんNGNG
234はSCMをしないPRJにしかいたことがないようだな。
変更管理をきっちりすれば同期問題はおきないぞ。
0241デフォルトの名無しさんNGNG
>>240
だから、変更管理をきっちりしてる
プロジェクトで仕事した事がない、って話なんです。
ちっこい案件は別だけど。
0242デフォルトの名無しさんNGNG
>>241
ＰＭがマヌケということか。同情するよ。
まぁ、悲観するな。そのうちまともなＰＲＪに出会えるから。
0243デフォルトの名無しさんNGNG
>>240
構成管理をきっちりしないと、同期問題がおきるってことでしょ。
で、構成管理をきっちりすることは、組織的な成熟度が高くないといけない。
適用しやすい開発方法論を考えるのなら、
「こうやればうまく開発できます。でもドキュメントが大切なので、構成管理はきっちりやってください」
というものはどうかと思う。

構成管理がきっちりできるなら、他の能力も高いことが多いから、どうとでもやってくれという感じ。
0244デフォルトの名無しさんNGNG
　 　 　 　 　 　　 ＿＿＿
. 　 　 　 　　　　 |（･∀･）|
. 　 　　　　 　 　 |￣￣￣　　　ｼﾞｻｸｼﾞｴﾝ王国
　　　　　　　　　△
　　　　　　　 △ｌ　|
　　　＿＿△|_.田 |△＿＿＿＿＿
　　　　　　|__|__門_|__|＿＿＿＿＿|＿＿＿＿＿
0245デフォルトの名無しさんNGNG
データと振る舞いは別クラスにすべき、と言っている人たちは
TheBlobを避けるためにPoltergeistに向かっているように思うなー。

The Blob
http://www.antipatterns.com/briefing/sld024.htm

Poltergeist
http://www.antipatterns.com/briefing/sld030.htm
0246デフォルトの名無しさんNGNG
結局、適材適所
だからフレームワークは無用
プログラミングしよう
0247デフォルトの名無しさんNGNG
243は、ある程度の規模のPRJで構成管理をやらなければ開発は頓挫するという事実が理解できていないようだ。
まぁ、わからないでもないよ。最近は知ったかぶりのアジャイル莫迦が多すぎるからな。
JAVAWORLDも酷い記事を書くやつが増えたが、編集は何をやっているんだか。
0248デフォルトの名無しさんNGNG
>>247夜釣りご苦労。
0249デフォルトの名無しさんNGNG
ちなみにくーすの元ネタICONIXは、シーケンス図とかの中間成果物は
使い捨てで、ソースコードとの同期はやらないんだよね。
0250デフォルトの名無しさんNGNG
あれ？
捨てはロバストネス図じゃなかったっけ？
0251デフォルトの名無しさんNGNG
あれ？
捨てはロバストネス図じゃなかったっけ？
0252デフォルトの名無しさんNGNG
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
あれ？あれ？あれ？あれ？あれ？あれ？あれ？
0253243NGNG
元の話にもどすと、サーブレットフィルターやAOPやDBのトリガーなど、コードに現れない形で処理が分散するときには、ドキュメントを同期したにしても、ドキュメント自体が分散しがちで、結局わけがわからなくなりそう。
もちろん適切に使えばよいけど、一度乱用する時期を経ないと適切に使えないと思う。
プロジェクトの発言権を持った人の中に乱用する時期の人がいる可能性も高い。
0254243NGNG
まとめれば

「ドメインモデルは、複雑なコードを整理しやすいのがメリットだ。
ただ、開発者にとって理解しにくく、またRDBMSとのマッピングが複雑になる。
そこで、ORマッピングレイヤを設けなくてはならない。
そのため、ドメインロジックがシンプルな場合は、トランザクションスクリプトを採用した方がいい。」

ということだ。やっぱファウラータンは俺のために言葉を用意してくれてて偉いな。
ttp://www.ric.co.jp/sol/contents/sol_0407/sol_architect.html
0255デフォルトの名無しさんNGNG
>>254
そんな考えはレガシーで、ドメインモデルは複雑な
ロジックを記述するには向かない
という考えってどうよというのが先週からの話。
少しは流れを嫁。
0256デフォルトの名無しさんNGNG
>>255
つまり、すごく複雑ならドメインモデルでちょっと複雑ならトランザクションスクリプトっていってるのを、すごく複雑でもトランザクションスクリプトでってこと？
0257デフォルトの名無しさんNGNG
お父さんは貧血症
0258デフォルトの名無しさんNGNG
>>256
この辺かな。
http://d.hatena.ne.jp/higayasuo/20041223#1103771319
1週間くらい前からいろいろもとねたがある。
0259デフォルトの名無しさんNGNG
ドメインモデルを作っても貧血になっちゃうからよくない、と。
0260デフォルトの名無しさんNGNG
> １．あるコンポーネントは自分で処理するか、自分よりも詳細なことを知っている別のコンポーネントに処理を任せる。
> ２．1を再帰的に繰り返す。

構造化じゃん。
0261デフォルトの名無しさんNGNG
>>260
メソッド分割なのかコンポーネント分割なのかという話だと思うよ。
ちなみにそれが構造化ならあらゆる処理がが構造化。
自分で処理するか他人に任せるしかないんだから。
0262デフォルトの名無しさんNGNG
ドメインモデルを適切に構築するのは難しいから、いっそのことトランザクションスクリプトでってこと？
でも、トランザクションスクリプトじゃない、って書いてある。

ここに書いてあるのは、トランザクションスクリプトを構造化したらいいって話だよね？
そしたら、コマンドパターンっぽく切り替えやすくなると。
構造化って、おおざっぱなものが細かいものを再帰的に内包するモデルのことだよね？
違うの？
0263デフォルトの名無しさんNGNG
デマルコの「構造化分析とシステム仕様」に、なんだかそのものズバリの図が書いてあるんだけど・・・。
で、Javaだと、ひとつの処理をひとつのオブジェクトに割り当てるといろいろ切り替えれて便利、っていう話だと思ったんだけど。
0264デフォルトの名無しさんNGNG
Javaの場合は関数ポインタもないし、言語仕様としてはメソッドはオブジェクトではないからクラスに追加したり切り替えたりできない。
ってことで、オブジェクトに持って切り替えれるようにしましょうってことでしょ？
切り替える用途やら規模によって、ストラテジーだとかコマンドとかステートとか、いろいろパターン名が変わるだけで。
0265デフォルトの名無しさんNGNG
>>262
たぶん、構造化というよりは、自分の役割だけをこなしてあとは、
人に任せるということなんだと思う。
ドメインモデルは、1つのクラスに役割が集中しすぎる危険性があるという話。
0266デフォルトの名無しさんNGNG
>>265
言い方が違うだけで、構造化とやってることは同じだと思うけど。
人=オブジェクトって考えが出てるけど、これはJavaの言語仕様上オブジェクトが便利なだけで。
関数ポインタが使えるか、メソッドを代入できる言語では、オブジェクトである必要はなさそうだし。
そのオブジェクトはステートレスなんだよね？

つまりは、ドメインモデルを適切に構築するのは難しいから、構造化されたトランザクションスクリプトで、ってことでしょ？
0267デフォルトの名無しさんNGNG
で、手続き呼び出しの構造化ツリーの構築にDIが便利と、そういうことでしょ？

ただ、ここでインターフェイスを持ち出してくる必要があるのかないのか。
インターフェイスはテストの都合で必要なわけで。
処理を動的に切り替える予定がない部分をインターフェイスにする理由は、それしかないよね？
0268デフォルトの名無しさんNGNG
あ、AOPもか。
0269デフォルトの名無しさんNGNG
なんかトランザクションスクリプトってことになんとか持っていきたいように思えるが、
「モデル」部分を「単純なデータ保持／DBアクセスオブジェクト」として完全委譲した
だけで、これはドメインオブジェクトだって理解した方がいいんじゃないの？

トランザクションスクリプトってのは、サービス層でDBアクセスも全部世話して、呼び出した
メソッド一つで全部やってしまうようなもんだろ。

プレゼンテーション層 -> サービス層（薄い） -> ドメインモデル（モデルを基準に分割／ORマッピングもする） ->DB
が
プレゼンテーション層 -> サービス層（薄い） -> ドメインオブジェクト（サービスを基準に分割） -> 薄いモデル（ほぼORマッピングだけする） -> DB

になっただけなんじゃないの？ どっちみちサービスの連鎖の開始ポイントとして、Facade的な
薄いサービス層は現れてしまうし。
で、薄いモデル部分がドメインモデルと比べて明らかな貧血症だから騒いでるだけだろ。
俺にはデータアクセスをドメインモデルから外に出して、分割の基準を変えたように見える。
0270デフォルトの名無しさんNGNG
トランザクションスクリプトじゃなんで嫌なのかがよくわからんけど、先のblogだけ見ると構造化されたトランザクションスクリプトにしか見えないんだよね。
結局サービス層のことをドメインと呼んで、その前に置いたコントローラー的な層をサービス層と呼んでるんじゃない？
で、実際にドメインになる部分が薄くなって、「ドメインモデル貧血症」になってるからどうこう言ってるんじゃないの？

いや、よくわからんのだけど。
0271デフォルトの名無しさんNGNG
分割の基準を変えたように見えるという点では同じかな？
0272デフォルトの名無しさんNGNG
>>267,268
学生ですか？
機能拡張とか仕様変更とか、手作業でトランザクション制御する手間とか
納期とか考えたことある？
0273デフォルトの名無しさんNGNG
> トランザクションスクリプトってのは、サービス層でDBアクセスも全部世話して、呼び出した
> メソッド一つで全部やってしまうようなもんだろ。

いや、ドメインモデルを構築する代わりに全部１つの流れでやりましょうっていう形。
だから、ドメインモデルと置き換わるはず。
で、もちろん１つのメソッド・ひとつのオブジェクトで完結する必要はないと思う。
サービス層は、適切なトランザクションスクリプトを呼び出す層ということになるんじゃない？
0274デフォルトの名無しさんNGNG
>>272
> 手作業でトランザクション制御する手間

トランザクションが必要で、それがAOPで実現されてるならインターフェイスを使うしかないね。
で、機能拡張とか仕様変更とかの話だと、ソース追う手間が増えることを考えると、一概に言えるのかなぁ。
ソース追う手間は、無視してしまえる程度にしか増えないものなの？
0275デフォルトの名無しさんNGNG
機能拡張とか仕様変更とかで、インターフェイスが便利なときは、そのときインターフェイス作るっていうのは？
いままでのクラスと同じ名前でインターフェイス作れば、ソースは変更しなくていいし、オブジェクトの生成はDIでやってるわけだからそこ書き換えるだけじゃないかなぁと。
0276デフォルトの名無しさんNGNG
ttp://www.nri-aitd.com/tips/g-patern.html
これなんか読んでると、別にトランザクション・スクリプトでもいいじゃん、という気になる。

おれ、ドメインモデルってモデル間が密結合しすぎのような気がするんだけど。
0277デフォルトの名無しさんNGNG
その記事に書いてある通り、どっちがいいかはビジネスロジックの複雑さに依るのだろう。
0278254NGNG
>>255
結論は同じところに落ち着きますた。
0279デフォルトの名無しさんNGNG
>>278
複雑な業務ロジックだと、トランザクションスクリプトには
向かないというのはなぜ?
別にトランザクションスクリプトはどうでもいいんだけど、
コンポーネント分割でDIで組み立てるやり方なら、
逆に複雑な業務ロジックに向いてると思うけど、
理由は、それぞれのコンポーネントは小さいから。
ドメインモデルは、複雑なロジックになればなるほど、
クラスは大きくなる。
0280デフォルトの名無しさんNGNG
>>279
複雑な業務ロジックをやる予定は、今しばらくないので、「ファウラータンが言ってるから」で済ませてるんだけど、だめ？
なにか説明するにしても、ファウラーの言葉の引用になりそう。

とりあえず、ドメインモデルとトランザクションスクリプトの違いは、オブジェクトが状態を持つか持たないかだと思うけど。
で、複雑な業務ロジックの場合は、オブジェクトが状態を持ったほうが好都合なんじゃないのかなぁ。
0281デフォルトの名無しさんNGNG
ドメインモデルで複雑なロジックになればクラスが大きくなるというのなら、そのときトランザクションスクリプトならそれぞれのコンポーネントを小さく保てるのはなぜ？
0282デフォルトの名無しさんNGNG
>>281
複雑なロジックを単純な役割に分割してそれぞれの役割にコンポーネントを
割り振るからだろう。
それぞれの役割は単機能だから小さい。
ドメインモデルだとデータに対して振る舞いを割り当てるから、
複雑になればなるほど、やらなければならない役割が増える。
0283デフォルトの名無しさんNGNG
>>280
> >>279
> 複雑な業務ロジックをやる予定は、今しばらくないので、「ファウラータンが言ってるから」で済ませてるんだけど、だめ？
> なにか説明するにしても、ファウラーの言葉の引用になりそう。

引用は別に良いと思うけど、理由を説明できなければ意味はない。
ファウラーたんも盲目的に信じて欲しいとは思ってないと思うけど。

> とりあえず、ドメインモデルとトランザクションスクリプトの違いは、オブジェクトが状態を持つか持たないかだと思うけど。

そんなことどっかに書いてある?
0284デフォルトの名無しさんNGNG
トランザクションスクリプトだと単純な役割に分割できるときに、ドメインモデルだと単純な役割に分割できないことになるのはなぜ？
0285デフォルトの名無しさんNGNG
>>283
> そんなことどっかに書いてある?

そうじゃないの？
0286デフォルトの名無しさんNGNG
>>284
>>282に書いてあるじゃん。分割単位が役割じゃなくてモデルだからだろ。
0287デフォルトの名無しさんNGNG
そのモデルが適切に分割できないということになるのはなぜ？
0288デフォルトの名無しさんNGNG
さあ？ ＤＢのテーブル構造に依存しちゃったんじゃないか？ モデルって永続化のやるしねえ。
0289デフォルトの名無しさんNGNG
逆に、モデルを適切に分割することができないとして、そのときトランザクションスクリプトを細切れに分割したところで、おおきなドメインのモデルよりも有効だと言えるの？
トランザクションスクリプトはいくらでも分割できるだろうけど、そのとき大きなドメインのモデルよりいいかどうかは疑問に思える。
杞憂なのかな？
0290デフォルトの名無しさんNGNG
>>288
ORマッピングで、１つのテーブルをいくつかのオブジェクトにマッピングできるものもあるわけだし。
0291デフォルトの名無しさんNGNG
>>289のいいたいことがよくわからんのだが、ドメインモデルに比べればそんな利点は霞むと
いいたいのか、大して変わんないんだからドメインモデルでいいじゃんといいたいのか、
言ってることに利点など何もない、問題は存在しないといいたいのか。
0292デフォルトの名無しさんNGNG
スレ違いだけど、ちょっと気になったんで、確認させてください。
デマルコの「構造化分析とシステム仕様」は、「構造化」の原典のひとつだと思って引っ張ってきたんだけど、違ってる？
■ このスレッドは過去ログ倉庫に格納されています