DevLOVE Beautiful Development( #devlove, #devlove0409, #DDDjp )参加メモ

イベント

DDDに関するカンファレンスへ参加した際のメモです．


■イベント名：DevLOVE Beautiful Development
　-Tackling Complexity in the Heart of Software ソフトウェアの核心にある複雑さに立ち向かう
■日時：2011/04/09(土) 13:00-20:30
■場所：オラクル青山センター
■参加者数：90名位

■資料


■プログラム

  • 13:00-13:30 オープニング
    • 和智右桂(@digitalsoul0124)氏, papanda(@papanda)氏
  • 13:40-14:20 第一枠
    • 陽の巻 都元ダイスケ(@daisuke_m)氏
    • 陰の巻 じゅんいち☆かとう(@j5ik2o)氏
  • 14:30-15:10 第二枠
    • 陽の巻 渡邉健太郎(@kentaro714)氏
    • 陰の巻 角田直行 氏
  • 15:10-15:40 しばし休憩
  • 15:40-16:20 第三枠
    • 陽の巻 和田卓人(@t_wada)氏
    • 陰の巻 綿引琢磨 氏
  • 16:30-17:10 第四枠
    • 陽の巻 増田亨(@masuda220)氏
    • 陰の巻 佐藤匡剛(@tadayosi)氏
  • 17:20-18:10 キーノート
    • 和智右桂 氏
  • 18:30-20:30 ビアバッシュ
    • LTもあり．


■イベント概要&感想

  • このイベンは，和智さんと開発者のコミュニティDevLOVEが，Domain Driven Design(DDD)日本語版の発売を記念して開催したもので，DDDに造詣の深い方々による2パラレルセッションの講演でした．2パラレルセッションのどちらを聞くか悩みましたが，DDD本を読んでいなかったので，DDD本を読む際の枠組みや視点を与えるという陽の巻を聴き続けることとしました．ただし，陽の巻であっても本を紹介するというより，自身の経験に基づいて，本の内容やDDDというものについて語るという充実した講演でした．DevLOVEはYouTubeで講演を公開する(公開NGのもの以外)ので，復習ならびに見られなかった陰の巻の講演を見るという意味で，今から公開が楽しみです．

■papandaさんと和智さんの前説感想

  • 和智さんの前説を聞いていて，DDDは長い時間をかけて広まっていくだろうと感じました．中長期にわたって改善していくようなソフトウェア開発で最も効果がある設計方法であり，短期だと効果が分かりにくいため，逆に急激には広まらないだろうなと思います．ドメインが比較的安定している自社開発や組込み系では案外，あっさり広まるかもしれませんが．

■13:40-14:20 第一枠 陽の巻 都元ダイスケ(@daisuke_m)氏の講演

  • 都元さんの講演の最後にあった，”DDDは考え続けるためのパターン”という言葉は新鮮でした．パターンというと，パターン自体は決まったものであり，それらを当てはめることで効果を得ると考えていたのですが，パターンが自分たちで考え続けていく際の指針になるとは思っていませんでした．

■14:30-15:10 第二枠 陽の巻 渡邉健太郎(@kentaro714)氏の講演

  • 渡邉さんの講演は，シンジケートローンの管理という問題を通して具体的に深いモデルを作っていくものでした．まず，最も関心のあることに関してモデリングする．次に関心事をさらに深く考えてみると，漏れていることがあるので，それを追加する．これを繰り返すことで深いモデルを獲得する子ができるのだということが具体的に見えました．

■15:40-16:20 第三枠 陽の巻 和田卓人(@t_wada)氏の講演

  • 和田さんの講演では，数々の参考文献を紹介して下さり，DDDを抜きにしても，ソフトウェア開発に携わるものとして読んでおきたいと思いました．また，ペアモデリングでは，ペアを組んでいただいた方とお互い遠慮してしまったため，あまりうまく作成することができませんでした．時間も少なかったので，もう少し時間をかけてやりたかったなと思いました．ペアを組んでくださった方ありがとうございました．皆がわかるネタを題材として，ペアモデリング勉強会とか開催すると面白いかもしれません．

■16:30-17:10 第四枠 陽の巻 増田亨(@masuda220)氏の講演

  • 増田さんの講演は，実際に業務でDDDをおこなっている人ならではの，どうやってDDDをおこなうかという講演でした．DDD本ではあくまでパターンであり，それらを業務で利用するには様々な問題があるのだと思います．それらを，私のようなDDD未経験者へ見せるとともに解決のアイディアを示してくださるという，とても興味深い講演でした．DDD本を読んだ上で聞くとさらに面白いのだろうなと思います．

■17:25-18:15 キーノート 和智右桂(@digitalsoul0124)氏の講演

  • 和智さんの講演を聞いていて，有機的秩序をどのように保つかが気になりました．DDDでなくとも，システムのモデリングをおこなうと，ドメインをうまくモデリング出来ていないものの，なんだかんだでコンテキスト境界ができあがるように思います．その状態のモデルは，コンテキストごとのドメインエキスパートのメンタルモデルをモデリングしたものとなり，統一性のかけたモデルのように感じます．統一性の意味を勘違いしているおそれもありますが，そんなこともあり，有機的秩序を保つことが気になりました．すっきりさせる意味でも，早くDDD日本語版を読みたいと思います．

■懇親会2次会

  • 言語としてのプログラム(JavaScript, Scala, Rubyなど)やDDD日本語版出版の裏話等々，熱い熱い話を講演者の方々から伺いました．お話を伺って，より一層しっかり本を読んでいこうと思いました．


■詳細メモ
■papandaさんと和智さんの前説

  • papandaさん前説
    • ソフトウェアの複雑さに，IやYouではなくWeで立ち向かう
    • 立ち向かう手段として，今回はDDDをテーマとしている．
  • 和智さん前説
    • DDD本で語られているものは，従来からなんとなく感じているものであり，新しいものではない．
    • ただし，見たことあるものに名前を与えたこと，名前を使いながら体系的に語ったことはすごい．
    • 使っていく中で理解は深まっていく本であり，神棚に飾る本ではない，


■13:40-14:20 第一枠 陽の巻 都元ダイスケ(@daisuke_m)氏の講演

  • "Build Blocks" -DDDと愉快なモデル達-
  • DDD本の第2部についての話
    • DDD本はJiemamyの開発に悩んでいたときに読んだ．役立った．
  • ドメインとは問題領域であり，ソフトウェアがそもそも解決しようとする関心事
  • ドメインを分離するパターンである，Layered ArchitectureパターンとアンチパターンのSmartUIパターンについて
    • Smart UIパタンはDDD本内で記述される唯一のアンチパターン
      • モデル駆動とSmartUIパタンは両立しない．作るものがLightならMDDいらない
      • なにもしないと入れ込みやすいので，名前をつけて意識しやすくしている．
  • モデルを表現するドメインモデルオブジェクトである，Entity，ValueObject，Serviceについて
    • 役割として，関係を限定する．
    • 関係の相互依存問題に関して．"Declaration&Reference"と"Repository"で解決をはかる．
  • Entity
    • 主たる責務は”特定”であり，本質的に属性によってではなく，連続性と同一性によって定義されるオブジェクト
    • エンティティは共有できない．
    • 思考停止の誘惑として，すべてのモデルにID持たせることがある．
      • おこなうとオブジェクトの管理コストが半端ない．適度におこなうよう思考し続ける．
  • ValueObject
    • 主たる責務は”説明”であり，ある特徴や属性を記述するが同一性の概念を持たないオブジェクト
    • 同一性・連続性をもたない
  • Service
    • 主たる責務は”操作”であり，基本的に操作は特定のEntityやValueObjectのモデルに属するが，特定に属させると不自由なときはServiceとして用意する．
    • 思考停止の誘惑として，操作を早々にEntityやValueObjectに属させることを諦めたものがTransactionパターン
    • 本ではドメインサービスについて言っている．
  • モジュール
    • スーパークラスで分類せず，ユビキタス言語で分類せよ．
    • システムをMVCでモジュール化するのではなく，fooやbar内でのMVCとしfoo/bar単位でモジュール化する．
  • オブジェクトのライフサイクル
    • FactoryとRepositoryで制御
      • ただし，単純ならオブジェクト自身が持つ方がシンプル．思考停止の注意点．
  • Declaration&Reference．
    • declarationはエンティティ
    • referenceはバリューオブジェクト
  • DDDは考え続けるためのパターン
  • 2部のナビゲーションマップ図にはモジュールが忘れられている．


■14:30-15:10 第二枠 陽の巻 渡邉健太郎(@kentaro714)氏の講演

  • "ブレイクスルー体験記-深い洞察へ向かうリファクタリング-"
  • DDD本の第3部のブレイクスルーについての話
    • PartI:モデルはどうあるべきか
    • PartII:基本的な構成要素は何か
    • PartIII:：深いモデルにどうやって到達するか
      • ドメインを理解していないとモデルが素朴なものになってしまう
        • それを打破して深いモデルにしていく方法がPartIII．
  • 深いモデル
  • モデリングで詰まったときには概念が抜けているのではないか，と考える．
    • 小さな概念の取り込みを軽視しないこと
    • 最初から汎用的につくろうとしないこと
  • 月に行く方法として，DDDをスタンバイしておきたい．


■15:40-16:20 第三枠 陽の巻 和田卓人(@t_wada)氏の講演

  • DDDの歴史に関してと，DDD本の第1部について話をする．
  • DDD本の発売は2003年と少し昔であり，技術などは進化しているのが，DDD本自体は技術に特化しているわけではないので，価値は減じていない．
  • DDDに関しては，数々の参考文献が存在する．
    • PoEAAとDDDは技術的には連続性がある
  • DDD本のパターンの書き方は，Alexander本スタイル．
    • ”Therefore:それゆえに”に注意して読んでほしい．
  • ユビキタス言語：言葉大事．皆同じ言葉を使う．
    • 英語と日本語問題はどうするのか．日本語使う，対応表使うなど解決策を皆で考える．
  • モデル駆動設計：ドメインと実装両方の目的に使える単一のモデル
    • 同一でないと，現実からフィードバックできない．
  • 実践的モデラ：皆がモデルに触れられるようになっていないといけない．
    • コードの変更に対して責任を負う人はだれでも，コードを通してモデルを表現することを習得しなければならない．


■16:30-17:10 第四枠 陽の巻 増田亨(@masuda220)氏の講演

  • "実践！ドメイン駆動設計"
  • ソフトウェア開発の最も重要な仕事はドメインモデルの設計
    • うまく設計したドメインモデルを中核にしたシステムは，ソフトウェアの変更を，劇的に，簡単に，安全にするから
      • 変更(ソフトウェアを育てて続ける)が重要な関心ごとでないなら，ドメイン駆動設計は余計な時間と手間がかかるのでやめたほうがいいかもsしれない．
      • 単発の受託開発プロジェクトには向かないかもしれない．
  • 業務の関心ごと通りにソフトウェアができているのなら，業務の変更要求は容易に対応できる
  • 断片的な要求(業務の関心事)をわからないまま頑張るため，動くが正しくないソフトウェアが完成する
    • ねじれの原因として，業務の関心事に開発者が関心がないから．
      • 業務の用語をそのままクラス名やメソッド名にするのが良い設計．
      • 開発者同士で話すときに，業務の言葉で，議論しているか．
  • ねじれの対策として，開発のやり方を業務の関心事にする．
    • 1.ドメインモデル中心につくる，2.リポジトリを作る，3.アプリケーションサービスを作る，4.webを作る
    • ドメイン層を先に設計する
    • コードではなく，モデルで議論する．
  • ドメインモデル設計の関心ごと
    • パッケージ名，パッケージ韓の依存関係，クラス名，クラス間の関連，クラスの識別方法，メソッド名
    • ドメインモデルのクラス図とコードは常に一致させる
  • ドメインモデリングの設計順序
  • 今のプロジェクトにDDD適用 -DDD的コードリファクタリング-
    • プレゼンテーションとドメインの分離
    • 手続き的な設計からオブジェクトへ
      • 操作を関連する情報の近くへ移動する
    • 条件記述からメソッドを抽出する
      • 宿泊予約クラスの料金メソッドのみ，から，宿泊予約クラスの料金，夏季判定，夏季料金，冬季料金へ
    • コレクションのカプセル化
    • 値をオブジェクトに置き換える
  • ファウラーのリファクタリングの本は基本的にはドメインに関してのみ．
  • モデルリファクタリング -DDDパターンに向けて-
    • まず情報に注目する．
    • 次に操作に注目，整理する．
    • 操作を整理していく中で，関心事が分離されていく．
      • 変更が多いものがサービスとして分離されていく．


■17:25-18:15 キーノート 和智右桂(@digitalsoul0124)氏の講演

  • "戦略的設計入門"
  • DDD本の第4部について．本の1/3位．
  • 戦略的設計は3本柱．1.コンテキスト，2.蒸留，3.大規模な構造．
    • MDDは1人のドメインエキスパートのメンタルモデルを対象とするのに対し，戦略的設計では多人数のドメインエキスパートのメンタルモデルを対象とする．
  • 戦略的設計
    • 個々のモデルは，ユビキタス言語を用いたモデル駆動設計．
    • 0.知識の噛み砕き
      • いきなりぽんと絵が出てくるわけではない．話し合いながら．
    • 0'.言葉を共有しながらモデリングする．ドメインエキスパートがわかるとともに，実装に使われる．ユビキタス言語
      • 例：滞在(出発地，目的地)-移動
    • 0''.確立された概念体系を活用する．
      • 例では，グラフ．
    • コンテキスト
      • 1.コンテキストの境界を明確にする．境界づけられたコンテキスト(BOUNDED CONTEXT)
        • モデルが有効な範囲．
        • 例：「旅程作成」．「予約」移動手段や滞在先を予約する．「経理」実際に金銭を払う．
      • 2.コンテキストの内部を安定させる．継続的な統合(CONTINUOUS INTEGRATION)
        • 概念の統合と実装の統合．
      • 3.関係を明らかにする．コンテキストマップ(CONTEXT MAP)
        • 関係を定義する．本の14章．
      • 4.コンテキスト内で統合を保つための変換層．公開ホストサービス(OPEN HOST SERVICE)+腐敗防止層(ANTICORRUPTION LAYER)．
        • テクニカルな変換層ではなく，それぞれのコンテキストの意味の変換層．
      • 4'.無理に統合しなくともいい．別々の道(SEPARATE WAYS)．
    • 蒸留(抽出)
    • 大規模な構造(大局的構造)
      • 責務のレイヤ(RESPONSIBILITY LAYERS)
        • モデルの中で概念上の依存関係を明確化し，抽象的な責務を割り当てる．
        • 例：能力：商品，業務：旅程，意思決定支援：旅程ポリシー
      • 構造は成長する．進化する秩序(EVOLVING ORDER)．
        • 初期の構造にしばられると成長・変更できなくなる．
  • 有機的秩序(Organic order)
    • DDDに一貫して流れている1つのテーマ
    • 1つのオブジェクトから，それが集まってエンタープライズ全体を統合するに至るまで，それぞれの抽象度でモデルとしての統一性を失わない
  • DDDはビジネスに寄り添って成長していくシステムを作るための方法論