Webアプリケーション論
昨日のJavaEE勉強会で1時間強くらいの時間をつかって参加者で議論した。流れとしては最初ひがさんがWebアプリケーションのアーキテクチャの変遷を説明されて、その後議論開始!という感じ。
注) 議論の内容と私の感想が入り交じってます
- 古代はHTMLにLogicをがんがん書いていた(PHPとかPHPとかPHPとか)
- 近代、Strutsの登場によりActionが登場し、ViewとLogicの切り分けをしようとした
- ・・がみんなActionにLogicを書いた
- PofEAAの出版やSpringの登場は2002〜2003あたりなので、もうこのあたりにはそれをどのように分離するかということの議論は進んでいた
- 分離したモノを簡単に取り扱うためにはDIは必要だった
- ActionにLogicを書かないためにまず多用されたのはDao
- DBアクセスをActionからきりだす
- あと切り出されたのはService
- なんでTransaction Scriptがいけないの?
- ユースケース毎に切り分けて設計するのでロジックの重複がうまれやすい?
- ほんとに?
- Domain Modelでやればそんなことはないという主張があるが、ほんとにそれで重複はうまれないの?
- うまれるよ。
- さてこれから読もうとしているDDDではそのあたりは議論されてるの?
- 微妙・・・
- DDDとPofEAAで用語が違っていて、混乱することが多い
- ServiceとService Layerあたりが微妙にずれてる気がする
- というかこの場でいってる"Domain"という言葉もみんな同じモノになってる?
- ずれてる気がする
- Entity≠Domainじゃないよ。DomainにはProcessやRuleとかも入るでしょ?
- DDD読む上で用語集はいるね
・・・てな感じだった。(主観によってかなりゆがんでる可能性あり。しっかりとした議事録はこちら→第43回JavaEE勉強会 議事録)
最初はRailsの登場以降、少々のロジックだったらActionに書いちゃえという密結合でもいいじゃん路線になりつつあるのをそれってどうよ?という話になるのかなぁと思っていた(密結合と疎結合で、開発スピードと運用コストの天秤・・・みたいな話かなとか)が、全然違う方向に行きましたね。
私としては突如Serviceなんていらねーとひがさんがblogで書いたのが衝撃だったので、現時点のひがさんの感覚をきけてよかったですが。私はくーすを聞いてから今まで一貫してService必要派なので、やっぱいるよねと。まぁ、どうServiceを切り出すの?というところのさじ加減が共有しにくいというのは確かにあるんだが。
このような議論が今後も進んでいくと思うとほんとわくわくする。ただただ聞くだけではなく議論に加われるように勉強していかねば。