Java EE勉強会

議事録 / 第53回

議事録

第53回 Java EE勉強会 †

  • 日時: 2009年04月25日(土) 13:20〜

ポジペ: 次の書籍候補 †

小ネタ †

  • Anotation Processor
    • アノテーションからクラスを自動生成とかassertionとか
    • Slim3-Genで作成のデモ
    • Slim3-Genで制約のデモ
    • Eclipse はインクリメンタルなビルド
    • AbstractProcessor?を実装すればいい。Messengerでメッセージ出したり。
    • JPA2.0でも使ってるようだ

DDD読書会 (Chapter FIFTEEN. P397-414) †

Distillation †

  • そんなに複雑な内容ではない
  • コアに人的リソースを
    • フレームワークに人的リソースを入れがち
    • ビジネスロジックが新人とか中国とか
  • アプリケーションをユースケースごとに分解するのはよくない(後で出てくる)
    • ユースケースから出すんじゃないの？ ユースケースで分離しないって、どうやるのか
    • もっと粒度が大きそう。コンテキストとかのレベルでは。アプリ同士の政治？
      • 内容にはプログラムよりだけども
      • でも、アウトソース、パッケージ、なので、それくらいの粒度ではないか
  • 前の章との関連がイマイチわからない。BOUNDED CONTEXTとどう関連するんだろう
    • 14章は"統合"(粒度のあるものの結びつけ)、15章はまとまりから重要な物を取り出す
    • 14章と15章の粒度の関連が。15章もBOUNDED CONTEXT単位なのか
    • 背表紙やp.485の図を見る限りは、1 CONTEXT - 1 DOMAIN(= CORE DOMAIN)じゃないか
    • SEGREGATED COREではMODULEを切り出すだけで、別のCONTEXTにはなってない
      • MODULEとCONTEXTは同一粒度？ → DDDのMODULEだと、複数で一つのCONTEXT
  • アプリケーション内でのコアとcontextのコアがあるんじゃないか
    • 粒度は、システムによって異なりそう
  • ユースケースが理解を邪魔している気がする
    • ドメインモデルとユースケースは直交する

Core Domain †

  • DDDはアプリケーションデベロッパのためのもの
  • よくあるパターン
    • 年長の業務わかってるひと(技術わかってない) / 仕様決め
    • 技術ができる中堅 / フレームワーク
    • 新人 / ビジネスロジック
  • Developerは、日本でいうコーダーとは違うかもしれない
    • 書籍とズレてるのかもしれない
    • 向こうではプログラマは業界のTOP
    • アメリカでは、アーキテクトは哀れまれるらしい(可哀想なことがあってコーディングできなくなった人)
      • プロマネとかも
  • バランスが難しい
    • フレームワークは新人でいいの？？
    • 3割はチャレンジ要素で割り当てている ←勉強意欲
  • ここで言う技術 = オブジェクト指向設計。フレームワークがすごい出来る人、とはちょっと違いそう
    • モデリングの技術が高いと、テクノロジーの技術も高いんじゃないか
    • コーディングができない人とか・・・それはドメイン専門家？？
    • 技術のある人は、火を噴いた後に来る
    • 言語としての技術とモデリングはちょっと違う
  • コアが抽出できるくらいまで設計が煮詰まってれば、誰でもできるのでは
    • 画面の使い方、項目の定義も必要ではないか
    • コアかどうかわけるのは、もうちょっとアバウトなんじゃないか
  • "一つの企業として定義" → アプリを超えている。重い。
    • 競争優位性がなければ、外に出してもいい
    • 流出しちゃいけない技術はコア。人事系とか一般的なのはコアじゃなくていい
    • ソフトウェアとしてより、ビジネスとして、かもしれない
  • コアドメインがないアプリもあるんじゃないか
    • 自分たちで作らなくていいと言うことだろう
  • Distinguish ← 差別化、と言うよりは明確にする
    • チーム(企業)の"point of view"に依存する
    • ↑Evans的には、開発者も企業も同じユビキタスランゲージを共有してるはずなので
    • 汎用的であれば、コアとはならない
    • 海外はSIerって概念が少ないので、開発と経営が近いのかも
  • "making your CORE distinctive" は、「独特」なのか「明確」なのか
    • genericとの対比？ make CORE original とかでは
    • "distinguishing"は、「明確に」取り出しなさい
    • →「特徴づける」ではないか
  • 独特じゃないのであれば、パッケージを持って来てもよい
    • アプリケーションを作る目的となる中核
    • competitive advantage
  • 業務改革なレベル
    • 業務改善的な利点？
    • SOA的な話にも片足を突っ込んでそう
    • スコープでコアは違う
    • ユビキタスランゲージを実行してれば、コード的にコアは経営的にコア
  • ドメインはそこにある = competitive advantage
    • それをどう整理していくのか。はっきりさせていく
  • どこに人員を配置すべきか、と言うのがCOREを考えることではないか
    • COREをきれいに小さく保てば、リファクタリングがしやすくなる
  • Q. Deep Model と Core Domainの違いは？
    • ドメインはそこにあるもの。モデルはそれを表現したもの。
    • Deep Modelは、モデルが深まって行くこと
    • Core Domain は、重要な部分

An Escalation of Distillations †

  • 今後出てくるパターンのMap
  • 飛ばします

GENERIC SUBDOMAINS †

  • DOMAINなのかインフラ層 → COHESIVE MECHANISMS参照
    • 技術的な層の問題と、ドメイン的な周辺ドメインの問題がある
  • 単にsubdomain ではなく "Generic" → 結局COREが大事
  • アウトソーシング はコミュニケーション負荷が多過ぎるのでは？
    • オフショアでもレベルが高いことがある
    • コストが安いから使う。トータルで見ると3割安くならないと使う意味がない
    • インドは英語得意だから、英米圏だといい。中国・日本だと厳しい
    • 海外では特に顕著 → ブリッジSE(現地派遣) / 効率悪そう。でも安い。
    • 中国人には「バグ」より「仕様変更」と言った方がいい
  • 「品質」のためにオフショアと言う考え方もある
    • 例えば、インドのTOPの人達なので
    • 北米圏が駄目で、ウクライナの安い優秀な人を雇ったことがある
  • GENERIC SUBDOMAIN なので、失敗しても害は少ないでしょう
  • In House Implementationって家でやる内職？
    • いいえ。自社開発。
  • 外部の論文に「supporting domain(s)」ってのがあるが、なんなんだろう
    • DDDを北欧のガス会社で適用した例の論文らしい
    • supporting role ってのは本に出ている
    • GENERIC SUBDOMAIN っぽいけど？
    • GENERIC じゃないSUBDOMAINはないんだろうか
      • それをsupporting domainと呼んでいるのかも
  • COREはコンテキストな気もする
    • 複数のコンテキストに散らばっていてもいいのかも
  • motivation : プロジェクトの動機 となっているのが面白い
  • "generic models of these subdomains"となってるので、SUBDOMAINから genericなものを抽出しなさいと言うこと
    • SUBDOMAIN = GENERIC ではなさそう
    • 緻密に決められてはいなさそう
  • 自社開発の欠点のメンテナンス負荷って？
    • 自社でやるので。SaaSとかだと、法改正の追従
    • なぜ楽観的見積もりに？ → 契約がないから、なあなあになるのではないか
  • 4つのオプションがあるのが面白い
  • Off the Shelf と Published Modelの違いは？
    • 実装までできてるか、モデルまでなのかの違い
  • Generic Doesn't Mean Reusable が面白い
    • Generic はコードの再利用って意味じゃない
    • 再利用に注力するのはもったいない。メインがCORE。
    • Leave no trace of your specialities in them
  • 一番リスクが高いとこから手をつける
    • 技術的なとこに捕われがちだが、そうではない

スイーツ(笑) †

  • どらやき(うさぎや)

DDD読書会 (Chapter FIFTEEN. P415-437) †


DOMAIN VISION STATEMENT †

  • 設計書に書く「はじめに」的なもの
  • 新しく入った人のためにいいかも
  • これさえ書いてればDDDやってると言えるかも！ 「えーーー」

HIGHLIGHTED CORE †

  • CORE DOMAINの短いドキュメントを作る
  • ドキュメントにないものは自由に変えてよい
    • 抽象度を計るツールにもなる
  • Highlighted coreとしてファイリングするのか
    • そうでしょう。虎の巻的
  • 文章的な物なのか？
    • 技術者じゃない人も読めるように
    • UMLとかはOK
  • 作った人しか読まない、と言うのが難しいところ
  • このパターンはパターンの記法から逸脱してて読みにくい
    • 最後の太字の部分はなに・・・？
  • コンサルはIBMとかなのかなあ・・・

COHESIVE MECHANISMS †

  • これってS2DomainModel? ??
  • GOFのStrategyパターンを思い出した
  • MACHANISMがモデルの中核になりうる可能性があるってのは、実体験から来てるかもしれない
  • 銀行のアルゴリズムはCOREだが、実際にはCOREすぎて誰もアクセスできなかったらしい(p425)
  • CORE DOMAIN や SUBDOMAIN から COHESIVE MECHANISMが使われるイメージ
  • モデルとCOHESIVE MECHANISMSを分けて行くかが費用対効果の部分
  • CONTEXTなんだろうか？ → 違いそう
  • 再利用は？ - CORE DOMAINと結びついてるなら、再利用できなそう
    • 例: Graph なので、グラフ構造なら何でも使える
  • アルゴリズムならありものなら 持って来れる？
    • 形式化されているものがあれば、自信も持てるし、専門家に任せられる
  • ドメインモデルに現れるもの？？
    • P.424に、"does not represent the domain."

SEGREGATED CORE †

  • 一言で言うと・・・？
    • COREを洗練する。分離する。
    • ゴミを除く
  • 今までの話は、元々分離されてるものの仕分け。ここでは、COREを作り出していくプロセス。
  • p434 で、タグがついてないのがsupporting
    • 雰囲気がわかりやすい例
    • 結局、COREとGENERICとSUPPORTEDの3つになりそう
  • リファクタリングのステップはわかりやすい
  • 「凝集性が高いクラスとの関連が曖昧になったり複雑になったり」することがコスト
  • COREをいじるのは怖いと思う
    • やると、全体をいじることになるかも。存在してるモジュールが壊れるかも。でもやれ。

Abstract Core †

  • distinct classes は抽象の層に居る
  • COREを認識しやすくするために、抽象にする
    • 依存関係を少なくする
  • OSSのインタフェースが定義されてるパッケージのドメイン版

Deep Models Distill †

  • can change は、いい意味（軌道修正ができる）

Choosing Refactoring Targets †

  • pain-driven
    • hurt, pain : 目に余る部分、重要な部分、ではないか
    • 「痛みを伴う」？ 副作用が出やすい？
    • pain-driven と言う言葉としては、painは結論ではなく起点
    • "If there is a pain ..." っぽい。
    • TRYへ
  • 上の1が下の2、上の2が下の1に対応している

次回 †

  • 2009年5月23日(土)
  • 次回ポジペ「技術系以外のメディア(本/blog/TV/ラジオetc)」
    • [次回以降]最近出ている勉強会・カンファレンス
  • 次回は 16章から

Menu