議事録 / 第51回

議事録

第51回 Java EE勉強会 †

• 日時: 2009年02月21日(土) 13:00〜

ポジペ: 今年のトレンド予想 †

• Scala
• Haskell
• JSの代わりがあればなあ(NaCl?(Native Client)は流行らないでしょう)
• Objective-C
• バッチ系のフレームワーク(Hive, Apache Mahout)
• Cococaをもっと評価すべき
• ケータイ向けサービス、iPhone向けサービス(セカイカメラはない)
• Oracle Coherence
  • APサーバ間でメモリ領域を共有するミドルウェア
  • DB要らず。全てメモリ上で可能
• トルネードディスプレイ
  • ディスプレイが三つくっついている
• Selenium
• メッセージング
• DDD
• Silver light
• Python
• エンタープライズな分散
  • Hadoop, Google App Engine
  • Mule(オープンソースESB)
• SimpleModeler?
• クラウド Amazon EC2/S3
• github や Bitbucket
• コンピュータサイエンス
• Agile さっと作って納品
• Simple DB
• Key/ValueのDBMS → リレーショナルが重要
• RIA 見た目方向のアプリ
  • インタラクションデザイン
• Developer Test
• トレンドは出ないのではないか
• マネージメント側の知識
• SimpleModeler? -> XMind -> Scala -> Groovy
• Doblogがアル中向けコミュニティに
  • Mr.Nakagawaをイメージキャラクターに
• R (言語)
• DSL(Domain Specific language)
• S2DomainModel?
• 論理型言語Prolog ・・・はない
• Esoteric Programming Language (Esolang)
  • Whitespace
  • Grass
  • Brainf*ck
  • 「Rubyで作る奇妙なプログラミング言語」

DDD読書会 (Chapter THIRTEEN.) †

13章を先に行う。

Exploration Teams †

• the subject matter expertとは？？
  • Domain Expertのこと？
  • Domain Expertの中でも、その問題に特化した人
• "チーム"が重要視されているように思える
• 駄目だった時に、数日寝かすってのは面白い
  • 上の人に、「閃かないから、名案が浮かぶまでほっときます」とは言いにくい
  • イテレーティブだと受け入れやすい？ → イテレーティブでも、欲しい
  • 洗練してないものはあるはず。洗練を先延ばしにするだけ。
  • 変更を受け入れられないとなると問題になる
• 主力メンバーを喫茶店に連れ出すのは難しいかもしれない
  • 欧米では、パーティションがあって職場では話しにくいのかも
• ドメインエキスパートをすぐに連れ出せる？？一緒に働いてるの？
  • XP的にはその場に居て欲しいはず

Prior Art †

• 先人の知恵を勉強しておけ、と言うこと
  • 一度お客さんの仕事をやってみるのもいいかもしれない

Timing †

• CHANGE
• 概念がデザインに隠れているとは？
  • implicitな概念をexplicitの概念にできるってこと
  • 概念とメソッド名が一致し、クリアに見えるとよい
  • 概念を全てクラスにすることは不可能
  • 表面上の概念より、奥にある概念の方が抽象度は高いはず
• リリースの二日前ならいいのか(笑
  • カットオーバーではなく、イテレーションサイクルのリリースの意味合いでしょう
• Supple designの導入でドメインがおかしくなってはいけない

Crisis as Opportunity †

• ブレークスルー=「そういうこと！？」=手戻り
  • A period of steady refinement of a model がきっかけ
• Evansが、「全部Domein Modelでやるべきではない」と言っていたようだ
  • 「Transaction Modelでもいいんじゃないか」
  • どこにドメインモデルを使い、見分けるセンスが重要なのではないか
  • 要件をまとめる人が、手続き的に書いてしまうと、コードも引っ張られる
    • お客さんの捉え方がCobolぽい(手続き的)。再解釈が必要。
    • それはそれでいいのでは？
    • モデリングしたほうが、いいコードになりそう
  • バックエンドはドメインモデリング、フロントエンドは入れポン出しポンでいいのでは
  • そんな単純に分けれるのであれば、みんなこんなに苦労しない
• 手戻り、を、ポジティブに考えているように見える
  • 納期があるのではなく、継続開発してる人達
  • 「そういうこと！？」→「契約を5ヶ月伸ばせるぜ！」
  • イテレーションしてる場合は、将来のイテレーションで楽ができる
  • ソフトウェアは、土台を壊して作り直しやすい
  • ユーザからXPでお願いしますと要求されるようになるといい
  • 日経コンピュータで成功事例が出るのがポイント
  • リーン生産方式を引き合いに出す。「トヨタのやり方なんですよ」
    • ムダを無くす
    • 量産行程では成功するが、新しい発明を生むのは・・・？
    • 住宅もうまく行ってないらしい → XPを使うとしても設計部分。建築部分ではない(建築=build)

スイーツ(笑) †

• いちご大福

DDD読書会 (Chapter TWELVE.) †

Relating Design Patterns to The Model †

• モデルと対比させるため、設計パターンと約している
• デザインパターンはドメインパターンとしても使えるが、Doing so requires a shift in emphasis(注目すべきところをシフトする)
  • そのまま使える物と、概念だけ使える物がある

STRATEGY †

• 別名はPOLICY
• STRATEGYのconsequences(GoF本)は、そのままドメインにも適用できる
  • Javaでenum→STRATEGY→Visitor
  • consequences = エッセンス、の意もありそう

COMPOSITE †

• COMPOSITEはやりすぎなのか？
  • デザパタ的には、入れ子の構造をきれいにするもの
  • ドメインパターン的には、概念的に入れ子になっているものを見つけるためCOMPOSITEを使う
  • 階層が動的に変わるのであれば、有効。そうでないのならやりすぎ
• アナパタの責任関係 の抽象度の一番高い状態に似ている？？
  • party tettern → 個人と法人が入れ子になることはない
• VISITORはドメインパターンとしては？ → 使えない。テクニカルでしょう
• OBSERVERはドメインパターンとして使えそう → ドメインイベント
  • イベント、OBSERVERはドメインに存在してよい
  • メモリに常に乗ってるわけではないので、実装は難しい
  • ブローカー経由でリスナに通知する仕組みでなんとかなるかも(Entityはメモリから消えるので)
  • ブローカーはドメインには必要はない。実装の話。
  • RDBMSのように、インフラのイメージに思える。O/Rマッパのイベント版

Why Not FLYWEIGHT †

• デザインパターンを全てをリスティングする必要はない
• 概念的なものに触れてるデザインパターンはドメインパターンとして使える
  • 技術的な問題にだけ触れてる物は適用できない
• デザパタをドメインパターンに使える物と使えないものに分けてみると面白いかも
  • ★Java EEのwikiにまとめる？？

DDD読書会 (Chapter TWELVE.) †

Relating Design Patterns to The Model †

• モデルと対比させるため、設計パターンと約している
• デザインパターンはドメインパターンとしても使えるが、Doing so requires a shift in emphasis(注目すべきところをシフトする)
  • そのまま使える物と、概念だけ使える物がある

STRATEGY †

• 別名はPOLICY
• STRATEGYのconsequences(GoF本)は、そのままドメインにも適用できる
  • Javaでenum→STRATEGY→Visitor
  • consequences = エッセンス、の意もありそう

COMPOSITE †

• COMPOSITEはやりすぎなのか？
  • デザパタ的には、入れ子の構造をきれいにするもの
  • ドメインパターン的には、概念的に入れ子になっているものを見つけるためCOMPOSITEを使う
  • 階層が動的に変わるのであれば、有効。そうでないのならやりすぎ
• アナパタの責任関係 の抽象度の一番高い状態に似ている？？
  • party tettern → 個人と法人が入れ子になることはない
• VISITORはドメインパターンとしては？ → 使えない。テクニカルでしょう
• OBSERVERはドメインパターンとして使えそう → ドメインイベント
  • イベント、OBSERVERはドメインに存在してよい
  • メモリに常に乗ってるわけではないので、実装は難しい
  • ブローカー経由でリスナに通知する仕組みでなんとかなるかも(Entityはメモリから消えるので)
  • ブローカーはドメインには必要はない。実装の話。
  • RDBMSのように、インフラのイメージに思える。O/Rマッパのイベント版

Why Not FLYWEIGHT †

• デザインパターンを全てをリスティングする必要はない
• 概念的なものに触れてるデザインパターンはドメインパターンとして使える
  • 技術的な問題にだけ触れてる物は適用できない
• デザパタをドメインパターンに使える物と使えないものに分けてみると面白いかも
  • ★Java EEのwikiにまとめる？？

DDD読書会 (PART IV / Chapter FOURTEEN.) †

Strategic Design †

• 大規模な構造 → アンケートによれば 50人で6 BOUNDED CONTEXT とからしい
• 力不足とは？
  • 「ad hocなインタフェース でくっつけただけでは」、力不足
• サブシステム化しすぎるとドメインの意味が失われる？
  • 意味を失わない程度に
  • 人数単位とかで分けると、危ないかも
• 統合データベースブーム → データベースは一つにしろ的なもの
  • 達成できないでしょう。流行ったのは10年くらい前では？
  • マスタ系の統合は再び言われて来てる。MDM？？MMDとか？？
    • メッセージングによる同期であれば、ちょっと違う
  • サブシステムがDBをもって、メッセージングで疎結合させるのが最近の流れでは？
  • 統合データベース厨は身を潜めてるだけかもしれない

Maintaining Model Integrity †

• 不満タラタラ。吉野家コピペ的。
• 統合は現実的じゃない

BOUNDED CONTEXT †

• ベースがXPじゃないので、少人数でしょう
• アジャイルと言っても、チームを分けるだけじゃうまく行かない気がする
  • コミュニケーション重視の割には、チーム間のコミュニケーションは疎になる
  • それでうまく行くのは、大規模じゃないからではないか
• この例では、チームが初めから別れてそう
• 後半の例では、新しいBOUNDED CONTEXTが増えてる
• DDDの例では、意図的にパッケージ名が二つあったりする
• BOUNDED CONTEXTの分け方
  • サブシステムとBOUNDED CONTEXTはほぼ一致？
  • ドメインモデルの有効範囲で分ける？
  • 人数的な制約？？
    • 3人で開発すると3-passコンパイラができるという噂があったり
  • 理想はドメインモデル。制約を受けるから分割せざるを得ない？
    • パートナーが3社ならBOUNDED CONTEXTが3個？
    • 最初のチーム編成とその後のチーム編成が変わるとどうなるの？
    • →Shared Kernelとかになる？
  • 大人数でやってはいけない
• CONTEXTが違うとユビキタス言語も違う？
  • ユビキタス言語の方言があっていいのだろうか
  • 近い部分では、揃えた方がいいだろう

CONTINUOUS INTEGRATION †

• 概念の継続的インテグレーション、を言ってるのが新しい
• 実装側がインテグレーションされてれば、ユビキタスランゲージもインテグレートされそう
  • 実装が大丈夫でも、ユビキタス言語が壊れてることはありそう
  • 定期的なディスカッションが必要って話ではないか
• 実装のCIで出たエラーをきっかけに、概念側でもほころびがあるのではないか
• 概念のCIでは何を話すんだろうか？
  • 「オレの顧客はこうだ！」みたいな？？
  • 概念を口頭でテスト？
  • 業務の勉強会を継続的に
• データ辞書はユビキタス言語の一部

CONTEXT MAP †

• DDDの事例によると、CONTEXT MAPは他のパターンより圧倒的に使える
  • 逆に言えば、これから出て来るパターンはこれより使えない・・・？？
• 境界をどう扱うのかは出て来るの？
  • この後に続く6パターン(?)が、境界の扱い方を示している

次回 †

• 2009年3月28日(土)
• ポジペ「私は○○パターン厨でした/です/になります」
  • 次の本 ← 次回以降のネタ
• 次回は SHARED KERNELから(P.354〜) 14章 or 15章途中くらいまで