Java EE勉強会

議事録 / 第47回

議事録

第47回 Java EE勉強会 †

  • 日時: 2008年10月25日(土) 13:15〜18:30

ポジペ: 「コミュニケーションテクニック」 †

  • Yahoo! メッセンジャー
    • 友達登録してない人とも話す→終わり方が難しい→ウインドウを閉じるor「はーい」
  • 自然言語でのコミュニケーションには絶望
  • 「ご存知の通り」「なんでそういうことを言うかと言うと」
    • アンチパターン「あのー、えー、そのー」「ですかね」
  • コミュニケーションは、メンタルモデルの共有
  • 朝会(あさかい)
    • stund up meetingで15分程度
    • 昨日やったこと、今日やること
  • メールは恐い → 文面が残るので
  • IRC、メッセンジャー
  • 会社間のコミュニケーションは難しい → ドキュメントベース
  • 基本的にメールベース → 重要なことは、残しておきたい
  • wikiで共有
  • 煙草とお酒
    • 気がついたら山梨に居たりするので気をつける
  • なんのために話しかけてるのかを意識 → 報告、連絡、相談、ぼやき・愚痴？
  • 話しかけられたら、最後まで聞いてからリアクション
  • マンティスとかTrac → 結局Excelに
  • グループウェア(スケジュールとか)
  • アサーション → 偉い人にものを言う手法(書籍もあるらしい)
    • 代替論を示して拒否
    • 枕詞「申し訳ないんですが」
  • 社内SNS → 釣り
  • SkypeとかMSNは、気の利いたことを言わなきゃならないので嫌い → メールが楽

DDD読書会 (Chapter Five.) - その3(SERVICES, Modeling Paradigms) †

SERVICES †

  • Serviceはなんでステートレス？？ → 他の本とかの影響？？
    • ステートフルなクライアントがステートレスなServiceを呼び出すのが自然では
    • 両方ステートフルだと、矛盾が起きる(例えば、ブラウザとサーバ)
  • サービスとエンティティの分離は不可能？ - 区別しようってだけで依存性は言ってない
    • アプリケーション層のServiceも、ドメイン層に依存してもよい
  • ServiceとEntityへのメソッドのどちらにすべきかの基準が書かれてない
    • 安易に剥ぎ取ってはいけない
  • Serviceは、ドメイン層のインタフェース？
    • インタフェースとなるが、それが全てではない
  • Smalltalk のMVCのMは、プレゼンテーションモデルなのでアプリケーションレイヤ
    • ドメインモデルのMではない
  • EntityからServiceは呼び出す？？ → どこかにあったはず
  • アプリケーション層とは
    • ユースケースを実装するところ。ドメイン層は標準と思われるビジネスロジックを実装するところ
    • 区別は恣意的
    • アプリケーション層はユーザの主観により、ドメイン層は客観的な事実に基づく
  • アプリケーション層から作るか、ドメイン層から作るか
    • アプリケーション層の共通部をモジュール化 → 入れポン出しポンなら
    • ドメイン層から作る例: 新幹線の運行制御、航空管制
  • 入れポン出しポンのドメイン層はデータ構造。他のビジネスルールが入れば入れポン出しポンじゃない
    • 人間がビジネスロジックをやってたり
    • バックエンドがビジネスロジックやってたり
    • 昔はAccessがやってた部分を、WEBアプリが
    • FowlerとかEvansは入れポン出しポンの人ではないでしょう

Modeling Paradigms †

  • 具体性に欠けている。ルールエンジンとか使うと、モデルはどうなるのか
  • デリバティブで、モデルはExcelに書かれた数式だった
    • 解体してオブジェクト指向のEntityに変換。数式をそのまま実装はしなかった
  • モデリングのパラダイムが変われば、実装も変わるんじゃないか
    • オブジェクトパラダイム有りき？ ドメインを実装によらせている感がある。
    • この章までは、オブジェクト指向を意識してない → ENTITYとかVALUEとかSERVICESとかも一般論？ → 違うかも
  • DDDの主題は「ドメインを作る」じゃないですよね。ドメインからdrivenするだけ。
    • ドメインの洗練に関しては、「ユビキタスランゲージ」が全てらしい → 今後の主題は、どう実装に落として行くか
    • ドメインエキスパートが背後に居そう

スイーツ †

  • くりきんとん

DDD読書会 (Chapter SIX.) †

The Life Cycle of a Domain Object †

  • ModelがモノでDesignがプロセスだとしたら、FACTORYとかREPOSITORYはModelでは？
    • Designが"設計要素"と見なすと、Design？
    • 背表紙的には、MODEL-DRIVEN DESIGN から指されてるのはSERVICES, VALUE OBJECTS, ENTITTIES, MODULES

AGREGATES †

  • boundary とは？？ → 更新の単位。rootでロックして、中身を操作する
  • AGREGATEの入れ子はどう考えれば良いのか？
  • 一貫性を考えると、AGREGATEのboundaryが被っているとまずい
  • 入れ子で一貫性を保たなくても、親側で良いのでは？ スコープとか導入？？
    • 制約としてのboundaryは、子供も欲しい

FACTORIES †

  • P143の引数が下位のレイヤに依存するとは？
    • 参照が辿れるように、参照元のオブジェクトと言う意味では？？
    • 後半によれば、引数にドメインオブジェクトを渡さないとのこと。StringとかListでは？

REPOSITORIES †

  • enumirationが global search access が必要なのはなぜ？
    • VALUEオブジェクトは主キーからなるはずなので、検索不要に思われる
    • GLOBALアクセスしないと、列挙の一覧がわからないので ← 可変だと、列挙と言う意味合いは薄れるのでは？？
  • DAOはREPOSITORYで隠蔽すべきなのか
    • DAOをDDDの概念として使うために、REPOSITORYと言う言葉にしたのでは？(DAO=REPOSITORY)
    • REPOSITORYの下にDAOを置くと、REPOSITORYでアグリゲートを構築できる、と言う主張もあるらしい
    • 生S2DaoとかHibernateでできない部分を、なんとかする ← DAOの仕事では？
    • REPOSITORYはAGREGATEのルートにアクセスする手段ではないか ← で、DAOじゃん？
    • AGREGATEルートを扱うDAOがREPOSITORYではないか
  • ドメイン層にあるSpecificationをCriteriaとの変換とかしなきゃいけないの？
    • Criteriaそのまま使ってもいいかも ← フレームワークと戦うな！

Designing Objects for Relational Databse †

  • 「このユビキタスランゲージが目に入らぬか」
  • バッチもオブジェクトモデルで作らなければならないように読み取れる
  • この文章を読むと、テーブルとEntityは1-1に見える
    • 当初はHibrenateとかなかった。今のEvansの主張は違うかも。

DDD読書会 (Chapter SEVEN.) †

読み合わせまで。議論は次回。

次回、9章まで頑張りたい。

次回 †

  • 2008年11月29日(土)
  • ポジペ「自己啓発」
    • ○自己啓発
      • 英語とか、車のナンバー暗記とか、事務通いとか
    • (次回以降？)Javaに詳しいことを知るための質問
    • (次回以降？)私とUML
    • (次回以降？)私とモデリングパラダイム

TRY †

  • wikiにツッコミ入れた方が議論がスムーズ
  • 参加者を増やす
  • メールのフッタにwikiのURLを
    • Google groupにページも

Menu