議事録 / 第52回

議事録

第52回 Java EE勉強会 †

• 日時: 2009年03月28日(土) 13:20〜

ポジペ: 私は○○パターン厨でした/です/になります †

• Iterator
  • 結城さん本の最初の章なので
• DAO
  • ValueObject?
  • コード生成ツールもなかった
  • Generation Gap
• Template Method(多数)
• Command
  • Perl等で
• Singleton(多数)
• Factory
  • 過去形
• Proxy
  • 過去形
• Chains of Responsibility
  • 本来はチェーンの途中で処理が終わる場合に有効
• Transaction Script
• コメントを書かない厨
  • XP的な意味で
• State
• DOMAIN MODEL
• MICRO KERNEL
• DETOUR(迂回路)
• Adapter
• Visitor
  • パターンの中でもレベルが高い。やりたい
• Observer
• Composite
• Transaction Scripts
• Separate Ways
• Domain Model
• Naked Objects
• Extension Interface
  • POSA本 Vol2
• State
  • GoF
  • ドメインオブジェクトを抽象状態機械として表現

おまけ †

• Stack Stock Books http://stack.nayutaya.jp/
  • 積ん読管理

次回の読みたい本の案 †

• SOFTWARE COST ESTIMATION WITH COCOMO II
  • 安くなった

DDD読書会 (Chapter FOURTEEN. P354-373) †

Shared Kernel †

• 二つのCONTEXTの共通部分
  • コアドメインのこともあれば、端っこかもしれない
• 双方のCONTEXTのサブセットである、のが重要
• often the CORE DOMAIN(P.400) と書いてある
  • Kernelだったら、独立して別ドメインにしてもいいのでは？
• Shared subset じゃ駄目なのか
  • Kernel、が日本人が思うより「中核」と言う意味じゃないんじゃないか

CUSTOMER/SUPPLIER DEVELOPMENT TEAMS †

• 実際適用する時はどう説明するのか
  • 副社長が出てくる(笑
    • vice president: 日本で言えば、部長クラスでしょう
  • 上流が下流を顧客として扱うのは、コスト的な面で釣り合わない
• 会社が違ったりすると、うまくいかない
  • 元請けさんがきちんとやってくれればなあ
  • CONFORMISTパターンへ
• お金とか発生するの？
  • negotiate and budget tasks
• 上流が、下流チームの成果物を使う？
  • 上流が下流にものを渡す。下流が消費者。
• 上流と下流は、二つのBOUNDED CONTEXT
• スケジュール等は営業側(下流)が強い。インフラ側(上流)が、弱いのではないか
  • オンラインアプリとバッチ、等で考えた方がいい
• 営業が強いと、実現しやすいかも

CONFORMIST †

• 表紙の絵は、2009年の最先端(笑
• CUSTOMER/SUPPLIERができない
• 提供側がよければ、困ることはない
• 疎結合の観点からは、SHARED KERNELは必ずしもよくない
• ANTICORRUPTION LAYERがDDD的には有用？
  • コスト面でSHARED KERNELを選ぶ
• アンチパターンに近いかも。仕方なく使う。

ANTICORRUPTION LAYER †

• SOAとESBっぽいネタな気がする
• Service と Adapterの間に通信を入れないのはなぜ？
  • Adapterはpublicと考えられてないのでしょう
• subsystem が BOUNDED CONTEXT でしょう。
  • anticorruption layer: BONDED CONTEXTは？
• ANTICORRUPTION LAYERを作る人は？
  • 使う人が作る？
  • お互いが作る？？
• パッケージはどこ？
  • アプリケーション層
  • 違いそう. 語彙が足りない
• 双方向
• 「統合」とはどの程度のレベル？
  • SEPARATE WAYS だけが無統合？

Separate Ways †

• 訳は分離法、ではなく、「別れている道」
• P341(CONTINUAS INTEGRATION)とP371の写真の対比が面白い
• 例では統合は失敗
  • 統合への誘惑の強さを言いたかったのでは
  • 誤訳っぽい。「彼らの残せたものは、SEPARATE WAYSを歩んだそれらの小さなアプリケーションだけだった」→SEPARATE WAYSは価値がある
• 日本では統合の要求が強い
  • 総合メニューから行かなければならないじゃなければとか
  • ボタンからExcelが立ち上がらなければとか
  • 機能追加
• SHARED KERNELは共有
  • そうじゃなきゃCONFORMISTやANTICORRUPTION LAYERやSEPARATE WAYS
• P372 最上部: モデルは統合しない。UIやミドルウェアで、くっついてるように見せる

スイーツ(笑) †

• 名菓 みかも山

DDD読書会 (Chapter FOURTEEN. P373-) †

Open Host Service †

• WEBサービス？？
  • アプリケーションレベルのプロトコル
• PUBLISHED との区別は？？
  • 社内向けと社外向けの違い？
  • 通信技術では駄目。業界標準とならないと

Published Language †

• 一つ下と言うよりは、一つ上(OPEN HOST SERVICEを進めたことで)
  • Open Host Service は、CONTEXT内
  • Published Language は公開されたもの
• なんでLANGUAGE？？
  • FIX(？？)では、XMLだけじゃなくプロトコルも
• thereforeの直前で、"creating a shared domain model"で言ってる
• Open Host Serviceは、SERVICESとプロトコル

Unifying an Elephant †

• ことわざ「郡盲、象を撫でる」
• 4つのコンテキスト。
• 同じものを見て、違う認識を持つと難しい
• pathじゃなくてpass
  • passは通過

Choosing Your Model Context Strategy †

• 長い。個々の項目は独立している。TOPICS的。
• P388の上の表
• 要所要所でのガイドラインが書かれている
• Trade-offとかWhen Your Project is Already Under Wayは、「無理して一つのモデルにまとめない」
• 実感がない。応用だから？ 実例がないから？
  • 実際とてもうまく行くとは思えない
  • 考え中のTOPICかもしれない
  • Evansはこの辺の経験は少ないんじゃないか
• コンテキストの分離、くっつけたりする時の観点？？
  • コンテキストを決める時の(曖昧な)ガイド
• 誰でも思いつきそう
  • 思いつくようなことをキチンと書くのが難しい
• 今までの話を整理した？

Transformations †

• Duplication？ → Separate Ways同士の重複
• なんでSEPARATE WAYS なのに Translation overhead
  • Translation と mergeは一緒？
  • きれいな SEPARATE WAYS ではなく、統合に失敗した状態のことかも
• リファクタリング、と言う言葉はもう使ったので、使わなかった
• チームメンバの循環は無理でしょう
  • しかもSEPARATE WAYSだったはず
  • 循環すると人が減ってるかも
• PUBLISHED LANGUAGEは本当に有用か
  • 東北の人(OPEN HOST SERVICE)と沖縄の人が話すとき、英語(PUBLISHED LANGUAGE)で話すと辛い
  • 日本語がPUBLISHED LANGUAGEならまだいいのでは
  • PUBLISHED LANGUAGE に同音異義語があると、変換の際にバグになりやすい
  • よほど習得していて、汎用性がない限りは、あまり意味がない
  • 公用語が必要となってPUBLISHED LANGUAGEにするならわかる。OPEN HOST SERVICEをPUBLISHED LANGUAGEにするべきか
• OPEN HOST SERVICE が P388の表にあるのは違和感？
  • CONTEXTが複数になって来た時の連携なので、自然
• leads to lost oppotunities の意味が不明("lose"じゃない)
• やはりわかりにくい
  • Evansが経験が少ない頃に書いたのかなあ

次回 †

• 2009年4月25日(土)
• ポジペ「次の書籍候補」
• 次回は 15章から