議事録 / 第48回

議事録

第48回 Java EE勉強会 †

• 日時: 2008年11月29日(土) 13:00〜

ポジペ: 「自己啓発」(技術系以外で) †

• podキャスト(English as a second language.)
• 料理
• 睡眠時間を
• 洋書を読む
• DDR
• 朝のウォーキング
• 人に薦められたものを断らない
• ジョギング
• 散歩
• 英語のシャドーイング
• 映像記憶 : 詰め将棋
• 脳トレ
• フォトリーディング
• レーシックの資金集め : 自分への罰金制度
• 英語で書き込み
• λ計算、圏論
• Project Euler
• 東大のpodcat

DDD読書会 (Chapter SEVEN.)の議論 †

• REPOSITORIESはDAOと変わらない
• Handling EventはENTITIES？？
  • 時系列で言えば、一意性は必要
  • 「イベント」はエンティティじゃないかもしれないけど、記録すればエンティティでしょう
  • Fowler的には、ログでしょう
  • Handling Eventのtypeがenum
• 新しい構成要素と思われる"Domain Event"に関しての情報は？
  • MLやフォーラムだと埋まっちゃう。どこかにまとまってないかなあ。
• 循環参照を、実装で解決していいの？？
  • RDB的には、相互参照ではない(外部キーによる一方向の参照)
  • 本の例は汎用的ではなさそう
  • 概念の段階では循環参照は問題ではない、と言うのがこの本の主張
  • サンプルではHibrenateで解決・・・
• AGREGATE境界内に検索が必要な場合にどうするの？
  • AGREGATEは絶対重なりそう
  • AGREGATEはライフサイクルを見るためのツールなので、重なるとまずい→COMPOSIT的？
  • AGREAGTEが重なる＝モデルがおかしい＝モデルを直す瞬間、では
  • AGREGATEは、P.134のように明らかに一体となってる場合のみに使うのでは
  • AGREGATEは大したことない、説(佐藤さん)
• DDDのサンプルはどうなのか
  • 入れポン出しポンぽい
  • DDDのサンプルとしては拍子抜け
  • DDDってことを考えなければ、普通にできそう
• Handlig EventはAGREGATEに属さず、REPOSITORYもない。なんで？
  • ライフサイクルが違うから、AGREGATEには属さないでしょう
  • P169で循環参照について触れているとこで、後でRepositoryが登場するだろうことは書かれている
  • P172の段階では、Handling Eventを誰が永続化するのかは決まってないのでは？
  • Handling Eventを永続化すると言うユースケースがないから、まだ不要なのでは
  • グローバルアクセスが必要だと、REPOSITORYは必要
  • P171によると、Handling Eventは low-contention transaction で作られるためAGGREGATEに入れない
  • Handling Eventは、AGGREGATEのrootなので自由に呼んでいい
  • ライフサイクルを示すだけなら、AGGREGATEはUMLのcompositionで十分では
  • P128的には、黒塗りの集約(composit)ではない ←単に黒塗りは使ってないだけ？？
  • ユースケースによってAGGREGATE境界は変わりそう
• ↑リファクタリングと洞察が足りないのでよくわからないのでしょう(笑)
• P174. we still have to have a primitive constructor の真意は？
  • 言語使用的なのか、DDD的なのか
  • Java的には protect とかにしたいよね
• 親クラスが子クラスを返すのは気持ち悪い？
  • enumの実装は、これをやってる。気持ち悪くないでしょう
  • サブクラス名が親クラスにあるのは気持ち悪い。定義ファイルとかあればなあ。
  • 今後絶対増えないサブクラスなら、問題ない。enumでは、コンパイル時に確定して変化しないから
• Analysis Patterns の Enterprise Segment の説明が欲しい
  • 長くなり過ぎる。省略。
  • Analysis Patternsは役に立つかは別として面白い(koichikさん談)

スイーツ(笑) †

• 醤油とあんこのお団子

DDD読書会 (Chapter EIGHT.) †

今回はプロジェクタがないので、一つずつ議論しつつ進める。

Refactoring Toward Deeper Insignt †

• "why it does what it does"を表すコードとは？
  • コードでwhyは無理でしょう
  • コードで表す必要はなく、なんでそうするか理解できるようにする
  • モデルが洗練されていると、直感的にwhyがわかるのでしょう(best effort的)
• toとtowardの違い
  • 英語的には、toは目的地に着く。towardは向かっているだけ

Deep Model-Supple Design †

• P.50に、フィードバックループの図がある

Breakthrough †

• ブレークスルーが起きないこともあるのでは
  • 不要だったと考えるしか
  • 細かいりファクタリングを積み重ねるしかない
  • 頭打ちが来た時がチャンス
  • 日本の文化的にはブレークスルーは訪れない方が平和・・・

Story of a Breakthrough †

• 向こうのBOSSはこんなにいい人ばかり？
• 思い浮かんだブレークスルーが失敗だったらどうするんでしょう？
  • コード管理してれば、巻き戻せるはず
  • ビジネスエキスパートと話が合う合わないと言う点では、明らかに新しいモデルの方が優れている
  • イテレーションが小さいので、見通せるのだろう
  • 実話？？ → 実話ベースっぽい
• ブレークスルーと規模は関係ないでしょう

A Cascade of New Insights †

• ドメインエキスパートも使わないような新しい言葉が産まれてくるのか？？
  • ドメインエキスパートがわからない言葉はNGでしょう
  • むしろ、普段流していた言葉に、重要だと気がつくことでしょう
• P212 favorite domain expert

DDD読書会 (Chapter NINE.) †

Digging Out Concepts †

• 英単語は変わっているが、ここで出た5つの点について今後各節で掘り下げている

Listen to Language †

• 専門家の「it is normal(普通)」は開発者の言ってるnormarized(正規化)を勘違いしたものでしょう
• この話、実際はないでしょう
  • 開発者が暴走し過ぎ
  • ドメインエキスパートが我慢強い
  • 開発者の遠慮がなさ過ぎ(開発より)。これがユビキタスランゲージ？

Scrutinize Awkwardness †

• 開発者が自ら気がついてリファクタリング
• 「運」が2回入ってる → 運が重要なんでしょう
• 'Hard Way'な例なの??
  • ドメインエキスパートにはHard Way？
• Earning Interest は掛詞？
• 'By the Book'の方が楽？
  • 専門家に聞いた方が楽では
  • 他で使えない業務知識の本を読んで覚えてもなあ
  • 原発制御とか、本もないだろうなあ

Try, Try Again †

• 一発成功を目指すSIerでは無理でしょう
  • 話の分かる上司が必要
  • 上司は盾か壁か
  • お客さんの強力があれば
  • 検証フェーズだけなら
• 本読め、try again、ブレークスルーを目指せ
• モデリングの本ではない？
  • ビジネスモデリングの本ではない
  • DDDは、ドメインで駆動される"設計"の本であって、ドメインの本でもドメイン設計の本でもない(DESIGNがタイトルで一番でかい)

次回 †

• 2008年12月20日(土)
• ポジペ「振り返りをKPT方式で」
• 次回はCHAPTER9のP219からCHAPTER10