議事録 / 第44回

FrontPage

第44回 Java EE勉強会 †

• 日時: 2008年7月26日 13:00〜18:00

ポジペ: 「自分の定義する大規模開発」 †

• 都市伝説が囁かれたら大規模
• ピーク時100人以上、1年以上、費用数十億
• 顔も知らないメンバーが居たら大規模
• 自分が居るところ
• スケールアウト、マネージメントが必要な物
• 期間とか、人数
• 付箋で管理できるのが小規模、見たことない人が居るのが中規模、COBOLが大規模
• 月の売り上げの明細が400万件以上
• 組織間の壁があると大規模
• 5人×6チーム => 知らない人間が居ないから中規模
  • 難易度も夜間バッチのみなので簡単
• 1000人以上(デスマではない)
• はてブのネガティブコメントがたくさんついたら大規模
• 1年半くらいかかれば大規模
  • 内部統制資料が必要になる場合
• 提案段階から気合いが入っていれば大規模
• 階層が深くなって5〜7階層になってくれば大規模
  • よくわからないグループが出てくる
• 日経コンピュータに出てくるキーワード(SOA, SaaSとか)が出てくれば大規模
• 記事に載れば大規模
• これまで経験した人数よりも多ければ大規模
• 物理的な距離(国際協業、国籍が3〜5以上)があれば大規模
• 営業〜入金までの期間が長いもの
• 人を信じられなくなったら大規模
  • プログラマーを規約とかで縛り出して、軍隊っぽくなってくる
• 喫煙室が真っ白で見えなくなったら大規模
• プロジェクトルームの向こう側が霞んで見えないと大規模
• 知らないプロジェクトループがあったら大規模
• 赤字額で１億円で大規模
• ラージスケールストラクチャパターンが適用できれば大規模
• 1億円以上の案件が大規模
• チームが複数あれば大規模
• 未知の世界が大規模
• エンドユーザが見えなければ大規模
• 名刺を3〜4枚持たされたら大規模
• デスマでなければ大規模でない
• メインフレームなら大規模
• サブシステム30以上なら大規模
• EJBなら大規模
• 全社共通フレームワークとか使ってれば大規模
• 1000人月、10億円以上なら大規模
• 設計がごちゃごちゃしてて、破綻したら大規模
• NTTデータとかがやってるのが大規模
• 大規模なんて怖くない
  • 小規模の集まり
• コボラーが居れば大規模

DDD読書会 前半 †

• 日本でも、ユビキタス言語ではなくデータディクショナリと言う概念があった
• 実際に開発者とドメイン専門家が数十年イテレートして行くのは難しいのではないか
  • 金融系では7〜年のものがありうる。
  • 一刻も早く、法改正等に対応しなければならない。
• 十年越しのシステムなら普通にある。ドメインは変化し続ける。
• コードの書き直しの際、ドメインモデルがあるかないかでは大きく違う
  • 業界によってモデルの有る無しが別れてそう
  • 金融は持ってそう。よくある業務(受発注)であれば持ってない
• 金融系 (特にデリバティブ系) だと、ドメインエキスパート (金融工学の専門家) の仕事の成果 (数式や Excel のシート) がしっかりしていて、そのままモデリングされる
• ドメインエキスパートが確立されていると、モデリングされる → "新幹線の運行制御"など
  • ありがちな業務にはドメインエキスパートがいない？ → 販売とか
• "アプリケーションエンジニア"って人種が、OOPじゃないのはなんで？
  • PMとプログラマの板挟み
  • 清書屋さん
• ドメインエキスパートは、ドメインを母体としている人
  • IT／ソフトウェアを母体としている人ではない
• 言葉の定義
  • ドメインモデリングとドメインデザインはわかりにくい？
  • 読みながら把握して行く
• フレームワークではなく、ビジネスドメイン寄りのお話
• 正しいモデルはない、わかりやすいモデルがあるだけだ
• TimeAndMoney? のドメインモデリングのフレームワーク
• ドメインモデルはドメインごとに必要だが、共通化はされてもよい
  • 階層化される。低レベル層はあってもよい
  • ドメインの範囲を広げれば、希釈されて共通化されていく
  • ドメインモデルを構成するベースパターンの一つ

スイーツ(笑) †

DDD読書会 Part 1 後半 †

• ユビキタス言語は黒い太字になっている
• オブジェクトはモデルの1表現
  • モデルを関数型言語で表現してもいいが、適用範囲は狭いかも
  • 論理型言語でモデリングすれば関数型言語とマッチするかも
• The objects → 前のやり取りのComponent Typeとか具体的な実装を指すのでは？
• crunching → raw materialをcrunchingする
• どこまでcrunchingすればいいのか？
  • Continuous Learning
  • 生産性が一気に上がるブレークポイントがある
• どうして「自分たちがどのくらいわかってないかを理解できない」のか
  • 実装最中にもドキュメント等が散らばっている
• イテレーション前提
  • 分析、設計、実装ではなく、プロトタイプ作りながらモデリングするみたいな
  • XPの人達には当たり前のこと
  • XPやアジャイル前提の本である → XPしてない人には希望がないｗ
• 最初の段階で租借しておかないと、手戻りになる
  • 実はここは手戻りの話をしている → Continuous Learningだと手戻りにならない
• Continuous Learning であれば、新しい変化を Knowledge Cruncing しやすい
  • Chapter 10 の Supple Design で似たような話がでる
• Knowledge-Rich → 業務知識が豊富に入ったデザイン
  • 本当にドメインエキスパートで扱えるのか？
  • ドメインエキスパートが大事だと思うなら、モデルに入るべき
  • P19. に、詳細過ぎるのは推奨しない、と記述有り
  • お客さんにより、求められる粒度が変わる
  • お客さんが自分のドメインについて曖昧な部分もあるので、租借すべき
  • チェックをモデルの中に引きずり込む(差金決済とか)
• お客さんがモデルをどういう目で見るのか、まだ書籍には出てない
  • クラスをクラスとして見てくれるのか。自然言語として見るのか。
• 語彙、モデル、正しさ → 同じ物を同じ言葉で行いましょう
  • きれいと正しさは両立するとは限らない
• 正しさよりも、ビジネスを追いかけて価値を出すことの方が大事？？
  • ドメインモデルが重要だから
  • ドメインモデルに、結果としての正しさは含むのか？
  • モデルが間違えていれば、直せばいい
  • モデルと実装が乖離しないようにして、正しさを
• "Knowledge crunching" = "知識バリバリ"、じゃないですｗ
• ドメインとはどの範囲？
  • 本書ではビジネスエンジニアリングではなく、システムエンジニアリングの範囲
  • システム化する範囲に着目している
• ３ヶ月経って、倉庫での管理業務の情報が落ちていたのは、別の問題として大きいのではないか
• モデル作ったってだけで運用はしてないのでは？？
  • 運用して、knowledge crunchingしてが理想なので、運用してたのではないか

DDD読書会 Part2 †

• 日本語圏でも適用可能？
  • 訳語表を作ることで、対応可能
  • 日本語で書くときは、英語
  • public じゃないところは、そこまで重要じゃない
  • ペアプロすれば揃う
  • 難しさはあるかもしれない
• ユビキタス言語には、図表も含まれる

まとめ †

• 次回は2008年8月23日(P30〜)
• 次回ポジペ「私と英語」(時間制限厳しく！)

Problem「議論が長過ぎる」について †

次回は、担当ごとに議論ではなく、章ごとに議論の時間を設ける。