トップページ⇒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/
0173デフォルトの名無しさんNGNG
>>168
やっぱり給与計算となると、
皆自分の経験したり勉強した
実務の事考えちゃうんだと思う。

そうなるとはぶ氏のいってるような事を
考えちゃって、違和感を感じる、と。

＞160で、この例ではそこまで想定してないから
YAGNIだって書いてあるけども
簡略すぎて逆にイメージ湧かないんだと思います。
0174173NGNG
おっと、ちょうどそんなレスとかぶった。
＞172
そんな訳で、このお題に関しては、そこまではYAGNIらしいんだ。
0175デフォルトの名無しさんNGNG
44に逆に質問
図形クラスがあったとして、saveメソッドを図形クラスに持たせるべきかどうか？
複数の保存形式をサポートしたい場合、saveメソッドを図形クラスに持たせた場合と
別のクラスに持たせる場合で修正の影響範囲ばどちらが小さいか？

、saveメソッドを別のクラスに持たせる場合
-データ構造を公開することにより、疎結合性を妨害
-ポリモーフィックな振る舞いを持てない
-いくつかのデザインパターンの適用を妨げる(Compositeパターン等)
というデメリットが実際に起こるかどうか？

44はくーすがどうたらいう前に、オブジェクト指向を勉強しなおした方がいいと思う。
0176173NGNG
＞172
何度もすんません。せっかくだから自分でも考えてみた。

１はなるほど。

2は、社員クラスだろうと給与計算だろうと、変更のリスクは同じかなーと。
どちらかというと、そのリスクを回避するために、
テストがよりしやすいのはどっちかな？って話に持ってった方が吉だと思う。

3は、給与計算に出張旅費生産を組み込むのはちょっと仕事させすぎだと思う。
俺だったら経費の支払と給与計算は別にする。
仕訳も作ったりする場合、まったく別だしね。

最終的に銀行に振り込む情報を管理する機能（例えばFBデータを管理するクラスとか）や
給与明細を出力する機能はこれまた別じゃないか、と。

3はちょっと揚げ足気味かな、ごめん。でも気になったので。
ボーナスは、うーん、どうしよう。
0177デフォルトの名無しさんNGNG
170に賛成。
171は、障害出たとき、スタックトレースだけを頼りにしてるのか？
SQLExceptionだったら、どうするんだ？SQL文なくても分かるのと、分からないのあるだろ。
0178デフォルトの名無しさんNGNG
> それを考えるには色々な情報が必要になって一概に言えないので
> 簡略化する為に常にデータと処理を分離することにする。

MMRのキバヤシの口調に似てる。
0179デフォルトの名無しさんNGNG
ところではぶさんの日記みて、思ったんだが、直接S2とは関係ない、全般的な問題だとは
思うが、Strutsを使った時のDTO <--> ActionForm変換の手間をなんとかできんものか....
0180デフォルトの名無しさんNGNG
おれは逆に、「トランザクションを〜」のメッセージも障害解析時に使う、と
思ったんだけどどうだろうか。「あーここでロールバックしてるわ」とかそういう
情報になるしさ。
0181デフォルトの名無しさんNGNG
>>170
org.seasar.extension.jtaだけINFOにするとかで止めれるんじゃない?
0182デフォルトの名無しさんNGNG
どこに責任があるとかないとか考えて、モノによって処理が書いてある場所が微妙に違うのが一番困る。
0183デフォルトの名無しさんNGNG
それは無責任ですな。
018444NGNG
>>172
1と3のような要件の時にはcalculatePay持たすべきじゃないかもしれないけど、
「社員の給与は社員の役職によってのみ決まる」という場合には社員に持たせてもいいと思うんだけど、どう?

また、2の考えを押し進めると以下の(A)を(B)のようにするべきという話になると思うんだけど、こんなクラス、ちょっとありえないよね。
なので2の考え方は間違ってると考えます。

=== A ===
class Stack
　def push( o )
　　...
　def pop
　　...
end
=== B ===
class StackData
　...
end

class StackPush
　def push( stack_data, o )
　　...
end

class StackPop
　def pop( stack_data )
　...
end
018544NGNG
>>175
ごめん、質問の意図がわからないよ。
0186デフォルトの名無しさんNGNG
stackのpushとpopは対(つい)の操作。
calculatePayとisExpiredは無関係。
そんな例示でいったい誰を説得しようというのか。
0187デフォルトの名無しさんNGNG
>>184
> 役職によってのみ決まる

役職によって決まるんなら、役職に持たせれ。
018844NGNG
>>173
そっかー。
いろいろいい例を考えてはみたけど、漏れの貧弱な想像力ではいいサンプルが思い浮かばなかったんでつ orz
0189デフォルトの名無しさんNGNG
役職はクラスじゃないだろう。
給料の計算はPaymentCalculatorクラスにまとめるでどうよ。
019044NGNG
>>186
> stackのpushとpopは対(つい)の操作。
> calculatePayとisExpiredは無関係。
> そんな例示でいったい誰を説得しようというのか。

対の操作 = ひとつのロール、だよね。

172は、例えひとつのロールとして表すべきクラスでも、
エンバグの危険を避けるためにデータと処理を分けるべき、と言っていると思ってるんだけど。

もしそうじゃなかったとしたら、172の2の反論自体無効だね。
だって、おれは複数のロールを持つクラスをロールごとに分割することには賛成なんだもん。
0191デフォルトの名無しさんNGNG
>>189
> 役職はクラスじゃないだろう。

なぜ？
役職によって違うなら、役職ごとに違う処理を役職ごとに実装するのはありだと思うが。
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
学生ですか？
機能拡張とか仕様変更とか、手作業でトランザクション制御する手間とか
納期とか考えたことある？
■ このスレッドは過去ログ倉庫に格納されています