Seasar2 mini event @ 秋葉原・稚内北星学園大学東京サテライト校

メモです。あまり読み易いものではありません、あしからず。

●前半・tugboat.GTD
  Seasar2で開発されたポスト・サイボウズ的グループウェア。特にグループ
ウェアに興味があるわけではないので詳しくは述べないが、かなり良くできたシ
ステムだと思います。

●後半・Super Agile Web Development
　やはりひがさんのフレームワークに対する思想が聞けるのが良かった。現実の
開発現場で守りきれないオブジェクト指向を乗り越えるためのアジャイル的なア
プローチがSeasar2にあるのだと感じる。

レイヤー・アーキテクチャ
View - Presentation - Business Logic - DB
レイヤー間のinterface→これも強い信仰（疎結合）

問題点：
・クラスが沢山できてしまう
・管理しなければならないものが増える
　例：名寄せされていないデータ（在処がバラバラ）の表示（viewとBizLogicが
混在）
　　　→細分化されたクラスのどこに置くべきか分からない

　Fowler
　　ドメインモデル　ｖｓ　トランザクションスクリプト
　　※ドメインモデルの方がオブジェクト指向的として支持されているが、
　　　実際には日本では後者の方が好まれている。

◯オブジェクト指向と言う思想が大事なのではなく、早くきれいに保守性がいい
システムが作れればよいということ
【ユーザの要件と実装が近いことが理想】
　→要件変更に強い
　機能とオブジェクトを１対１にする
　『ユースケース』を表現したオブジェクト
　『ユースケース』とは何？→メニューを単位とすればよいのでは？
　個々のメニューの遷移上の複数画面：サブユースケース
　　→《ページクラス》（Teedaの基本POJO）
　※Light Weightに開発できかつ誰にでも理解しやすい

・ドキュメントと実装は開発中にどうしても乖離してしまう
　→ドキュメントが当てにならないのなら、ソースコードが分かり易い方がいい
　《共通的ユースケース》はドキュメントにも書こう！（難しいことじゃない）

◯ロジックがdaoへのディスパッチばかりに→ロジックはなくてもよい！
　（Entity or Serviceクラスに書けばよい）
　クラスが増えるとテストも増える