議事録
第43回 Java EE勉強会
日時: 2008年6月28日 13:00-
【ポジペ「最近読んだソースコード」】
- JTwitter(しゃべる)
- 社内コード
- ベンダー系
- jQuery
- Hadoop (MapReduce? + HDFS)
- ZendFramework?
- symfony
- Akelos
- Ruby(transcode.c), MacRuby?(string.c)
- Kilim(アクターモデルっぽいの, ASMでCPSに変換)
- Tomcatの "リムーブアダンタント"?
- CruiseControl?
- URI Template
- Apache shinding(PHP)
- Apache POI
- Hibrenate(の使い方)
- SICP(書籍,LISP)
- S2JDBC
- Eclipse3.4 プラグイン
- cursys??
- Haskell - Prelude(ライブラリ)
- JBoss jBPM
- S2Buri
- Nautica(ワークフローエンジン)
- Googleのcollection系
- java.util.ArrayList?
- Transate API(URLだけしかないらしい)
- Spring MVC, Batch
- RoR
- JUnit(読みやすい)
- CakePHP
- Prototype.js
- Clickフレームワーク?
- tangonist??
- screenフレームワーク?
- SAStruts
- Spring内のAspectJ関連
- jbehave??
- jdave??
- S2JUnit
【DDD読書会の進め方について】
[意見]
- 要約の資料を作ると、
- 負担が大きい
- みんな読まない
- →全員で少しずつ読む。
- wiki等に、翻訳を書き込む
- 参加表明 = サインアップ
- ☆Google group
- ☆pukiwiki
- パート1は読む。パート2〜4は序文を読んで、拾い読みは可能
- 部分だけだと、全体像がとらえにくい
- infomation retrievalは、id:naoyaさんが復習(まとめ)をしてる
- 読みたいのか、読んだこと前提で議論をしたいのか → 両方でしょう
- 2週間前にwikiに超訳、1週間前に議題をピックアップ
- 読むことを主体にする。まとめの会として、議論する
- wikiに超訳+感想+突っ込みを分けて書く
- 1ヶ月で50ページくらいやると、1年で終わる
[結論]
- 目次ベースで、1〜5P
- サインナップ方式
- 当日はwiki見ながら発表する
- 1週間前に〆切
【Java de Haskell/GLAD!!さん】
- Haskellっぽく組めるJavaライブラリ
- Preludeを実装
- Bool、Ordering、Char、()、関数 a->b、Eq、Ord、Showを実装済
- Int、リスト、String、タプル、Enum、Num、Maybe、IO を作成中
- 関数合成: _dot_ メソッドを利用
- 部分適用: apply
- 遅延評価: 基本型もクラスでカプセル化する
- Streamの遅延評価: IO.getContents
- モナドって?? → 次回へ続く
【Webアプリケーション論/ひがさん】
どうすれば保守性があがるか、ディスカッション。
- MVC
- Magic Button / ボタンにロジック書く
- 古代 / php + JS + SQL + HTML
- Smart UI / プレゼン層に色々入れる
- そんなに悪くない。1000行以下ならメンテナンスできる
- 2005年くらい → アクションに書きすぎない
- ビジネスロジックの分離。サービス(ファザード)クラス
- DAO(テーブルと1-1) | サービス層(ユースケース) | クライアント
- Transaction script / ユースケースに応じたロジック
- 複数のユースケースに対し、同じロジックが分散
- ドメインモデル
- 本当に重複を避けれるのか? 細かくしても問題は同じ気がする
- 重複は要件定義レベルで出てくるのではないか
- 責務は特定のドメインに属するから、重複を防ぎやすい?
- 処理を探す時、どのエンティティにあるかどのユースケースにあるかを探す難易度の違い
- ドメインには、エンティティだけではなく業務プロセスも存在する
- 永続化されないものもあるでしょう
- DDD的には、制約、プロセス、仕様、もドメインに入る
- こり過ぎると、現実に適用不能。単純過ぎると用が足りない
- サービスパターン:エンティティと"サービス"(ドメイン中の振る舞いを扱うもの)
- 何をサービスとして抽出する?
- ユースケースごとのロジックをサービスとできる
- ユースケースはアプリケーションレイヤ?ドメイン内のサービス?
- ユースケースの一文一文はサービス、その順番はアプリケーションロジック
- サービスレイヤー / PoEAAとDDDで定義が違う
- Daoを拡大して、ロジックを入れるといいのではないか
- エンティティごとにサービスを用意する
- 足りない部分に、サービスにサービスをDIする
- なんでエンティティとサービスを分けるのか
- エンティティは単なる記録(ログ)。振る舞いは分ける
- ドメインモデルによっては、"アクティブなエンティティ"は自然にはまる
- デリバティブの世界と伝票の世界の違い
- Employにsalaryを計算するロジックを積んではいけない
- そもそも、salaryを持ってるべきではない
- ドメイン逢いで、"給与支払いルール"が従業員にあるのは理解できない
- おそらく、本を読んでも答えは出ていない。プロジェクトごとの正解を決める価値基準を持てるといい(ひがさん)
- ドメイン≠エンティティ 言葉の使い分け
- ロジックとデータの改修頻度が同じであれば、分けなくても良い?
- Rubyでは、モデル(DB)とアクション
次回は、2008年7月26日(土)。
ポジションペーパー: 私にとっての「大規模」の定義。