9/5(土) 関西DDD.java スタートアップスペシャルに参加しました #kandddj

9/5(土) 関西DDD.java スタートアップスペシャル に参加しました。 会場は楽天株式会社 大阪支社さん。

内容は、エリック・エヴァンスのドメイン駆動設計本の各章について、ギルドワークスの増田さん (@masuda220) にお話をしていただくというものでした。 予定では16時からは質疑応答でしたが、なんと18時までセッション延長。 全17章についての概要と、また、増田さんがDDDを実践した中で感じたこともたくさんお話しいただき、とても濃密な内容でした。

私自身は今、DDDのプロジェクトに参加して3ヶ月程になるのですが、DDD本はまだ読んでおらず・・・。 仕事でふんわりとDDDがどういうものか体感はしているものの、言葉の大切さ、チーム内全員の共有の大切さなど、恥ずかしながらあまり意識できていなかったので、このタイミングで増田さんのお話をきけて本当によかったです。

ご登壇者の増田さん、また主催の@haljikさんをはじめとするスタッフのみなさま、有意義な時間をありがとうございました。

20150915 関西DDD.java スタートアップスペシャル – Togetterまとめ

イベント中にとったメモ

セッションを聞きながら取った雑なメモですが、公開します。 このメモを見返しながら、はりきって購入したDDD本と格闘したいと思います。

考え方と背景

• まえがきだけでも十分
• ドメイン駆動設計とは
  • 現場の技術者が失敗した・困ったことが載ってる
  • 技術者の奮闘の物語
  • 格闘して得た教訓の境地。共感できる
• 想定読者
  • オブジェクト指向とエクストリームプログラミングに知識がある人
    • ハードル高い
    • 勉強になった本
      • エクストリームプログラミング
      • Wabi Sabiをよみとく
      • リファクタリング
    • 変化に適応する技術
• オブジェクト指向の変更容易性
  • メッセージングはErlang
  • 抽象データ型
    • intとか基本型で日付・・・コンピュータ
    • 誕生日とか、人間の発想に近い独自定義クラス。ドメイン。
    • 人間の発想・目でないと設計できないメソッドとかをみつけにいくのがドメイン駆動設計
• 適応型の開発
  • 他(予測型や反復型)との違いは着地点
    • 予測型だと厳密だし、反復型だと、反復を繰り返しながら着地点を決めていく
    • 適応型はざっくりと定義するけど、最終形は事前に定義したり固定したりしない
      • リリースして、顧客のフィードバックをうけたりしながら日々変化
      • しょうがなく変化するのではなく、自分達で着地点を探しながら変化
• エクストリームプログラミング
  • ギリギリ余計な複雑さをもちこまない
    • コードによる確認
    • ちょっととなりの人やネットで確認することだってできる
• OO+XPはドメイン駆動設計といってもいいかもしれない
• ドメイン駆動設計が強調している点
  • モデルとコードの歩調をあわせる
    • 難しい
    • 最初は一致していなくてもいいから、ちょっとずつ改善していく
    • 今あるコードがどれぐらいモデルと一致しているか？
  • ドキュメントではなく言葉で
    • コミュニケーション命
• 俯瞰
  • 3部で成果がだせて4部
  • 2部は3部・4部の基本。2部だけでは意味がない。成果がでない。
  • 1部の内容をチームで共有することがポイント
• 着目のしかた
  • 1章・モデルの成長の様子がストーリーとしてわかりやすい
  • 7章・2部まとめ。
  • 8・ブレイクするーがおきたときにどういう現象がおきるか？
  • 13・深いモデルに向かっていくストーリー
  • 15・どういうところから手をつけて、蒸留に向かう様子が段階的に
  • 結論・3年後・5年後にヒアリングして、どうかわっていたのか。
    • ドメイン駆動に向かうエネルギー

第1部

• カタカナ言葉は伝達で問題を起こしやすい
  • 日本語にした方がわかりやすいよね
• ドメイン
  • ドメインではないもの
    • 私達開発者の活動
    • コンピューターの挙動
    • ソフトウェアを使う人達には関係のないことば
  • ユーザーに思いを馳せて言葉をほりにいく。探しにいく。
  • なんでそういう活動をしているのか。関心ごとになるのか。
    • そういうことを理解しにいってはじめて、わかる
    • そうとう広い範囲
  • 例えば受注管理という言葉がある
    • 営業マンにとって、月初と月末の受注は全然ちがうもの
    • 会社的に、月末にたてた受注は次の月初にさくっとキャンセルされたらアラートしてほしい
  • 利用する人達の活動と関心を要約
    • めっちゃたいへん
    • 重要な点にしぼって要約して理解しよう
      • それがモデリング
    • ユーザーがもってる関心を全て抜き出したらたいへん
      • 要約ということが非常に大事
    • 膨大な情報をいかにかみくだいて予約するか
      • 要約する力
        • 本質的ではないことを削る
          • 相当な論理力が必要
          • みんなで話し合うと、一人で発見するよりみつけやすい
        • 重要・重要ではないことにしるしをつけるぐらいはできる
          • それを説明するの、めっちゃたいへん。ハードル高い
            • それをチームでチャレンジして共有できたときのパワーすごい
• ドメインモデル
  • 本質だけを抜き出したものを表現したもの
  • 蒸留して重要な関心ごとを鋭く説明したもの
  • 重要な関心毎(ドメインモデル)をコードの骨格としてつかいなさい(3章)
  • 各章、浅い理解だと役にたたない
• 知識をかみくだく(1章)
  • 1章の読み方は、変化と成長
  • モデルが成長
    • ストーリーのイメージをチームで共有
  • コードで実験
• 2章
  • ユビキタス言語
    • ユビキタスは同一という意味ではない
    • 大切なのは、ソフトウェアを利用する人たちと共通の言葉を使うということではない
    • 営業マンにとっての受注と、要求設計書での受注は違う意味
      • 失注したときの痛みとか
      • そこに気が付きにいこう
    • 同じ意味っぽい別の言葉に敏感に
      • リクエストとか要請とか依頼とか違う意味。緊急度とか
    • ユビキタス言語の中で、特に重要度がたかいものがドメインに
  • 声に出してモデリング
    • 記録としゃべってることって違う
  • 説明のためのモデル
    • 背景知識をつたえるためのモデル
    • ドメイン駆動としてのモデルではない
    • なんでこれが2章の最後にぽんっとでてくるのかはわからない
  • チーム内で、一つの言葉を同じ意味で
    • チームが同じ意味で同じ言葉を使っているか
    • 3部とか4部とかの土台として脈々とでてくる
  • 言葉のたいせつさ
  • コードを書く人間がどんどん噛み砕いて積極的にユビキタス言語をつくりにいく
    • ここをさぼると自分の首をしめる
  • モデルと実装が一致しない
    • 原因は、優秀な人は頭の中で翻訳しちゃってる
      • 3ヶ月たったら説明できない
    • 常に、モデルをうまくコードで表現することをがんばらなければならない
    • モデルとコードが一致していないと、ねじれたソフトウェアになっちゃう
    • モデルとコードを一致させるテクニックを学ばなければならない

3部

• 役に立つモデル
  • とにかくリファクタリング
  • 言葉のたいせつさ
    • 言葉でしゃべったときの違和感に敏感になる
  • 設計自体が変更しにくいと成長しにくい
    • できるだけ変更しやすいソフトウェアをつくる
    • モデルとコードとの一致性を高めるために、柔軟にしておく。ここが勝負。
• 8章 ブレイクスルー
  • ブレイクスルーの経験を思い出す
  • 「理解した」ときの経験
  • 感覚を思い出した上でこの本を読むこと
    • この本からブレイクスルーを理解するのはむずかしいよ！
• 9章 暗黙的な概念を明示的にする
  • 超、肝になる部分
  • 言葉について、ちゃんと精査している？
  • 業務についての本を読む
  • 発見にたいして、何度でも挑戦する
  • 9章はとにかく読みこむ
  • 制約のなさに便利さではなく気持ち悪さを感じること
    • たとえば、何億年も前の誕生日が設定できたらおかしいよね
• 10章 しなやかな設計
  • 言語によっては言語仕様の一部
    • 関数型言語だったらイミュータブルあたりまえでしょ？
  • Javaは古い設計引きずってる
    • 10章の内容をJavaで実践するには結構がんばらないといけない
  • Java以外の言語の方が実践しやすい
    • Kotlinとか、良い言語かどうかじゃなくて。やろうとしていることはすごく勉強になる。
  • 10章は総合レッスン
• 11章 分析パターン
  • パターンにあわせにいくのは違うってことがわかればよい
• 13章
  • どういうタイミングで深い取り組みがおこなわれるか
  • リファクタリングのきっかけ
    • 言葉に違和感を感じた時
    • コードの理解が間違っていたと気づいたとき
  • リファクタリングのタイミングを間違えない
    • 動いているコードをなおしにいく
    • 選抜チームで取り組む
      • 考え方として大切
      • 深いモデルに挑戦する
      • 自分と違った知見をもつ人と話すことはすごく勉強になる
    • ユビキタス言語
      • 言葉で説明できないことを、コードで表現することはまずできない
• 3部まとめ
  • モデルとコードを一致させる
    • 言葉、コード、チーム

4部

• 意思決定がむずかしい
  • チーム間交渉など政治的な要因もある
    • そういうのも含めて考えなければならない
  • 巨大で複雑なシステムの成長を続ける
    • この意識を、チーム間・関係者間でいかに共有するか
• ここでも、言葉をつかった発見を強調
  • 全体的なものを動かすためには、コードを書く人間による言葉によるコミュニケーションがポイント
  • 現場でコードを書く人間が中核にかならずいること
    • そうすれば、戦略がコードに反映される
    • コードをいじる人間が戦略を考えるべき
  • すこしずつ、全体の秩序を改善していく
    • そうすればブレイクスルーが！！！
• 14章
  • こういうパターンのときにはこういう設計をしなさいね的なことがかいてあるよ
  • たとえばチーム間の言葉の不整合がおきたときに・・・
    • 言葉の違いを受け入れる？
  • チーム間の力関係
  • 受託開発なら、契約先が違うとかも壁
    • そういうことも考慮して戦略を考えなければならない
  • チームが同じ言葉を使っているかどうかということが境界
  • かかわっているひとたちの言葉が一致している？不一致を見つける努力をしている？？
    • それが継続的な統合
    • ドメイン駆動の文脈で読み取りにいかなければ、エヴァンスが伝えたいことはわからない
  • 費用対効果など
    • 政治的な問題も含めて、どういうところから手を付ければいいかの助言が載っている
  • こういう問題に対して、コードを書く人間がかかわらなければならない
  • こういうことに、アーキテクトチームが長期的なプランをかいたところで、成果はでない
  • コードを書く人間が中心になることによって、はじめて成果がでる
  • コアドメイン
    • 長期的になったらふくらむ
    • ほんとにコアなところをみつけにいく
    • 肝になるのは要約
    • ドメイン駆動設計を読むこと自体がコアドメインを見つける特訓に！！！！！！
  • 中核を探す準備
• 16章
  • 規模が大きくなったときに、森を見る力。俯瞰する力。
  • 俯瞰しないと、全体的にどうするかという話ができない
  • どんだけ複雑で大きくても、A41枚に収まる範囲までにしぼること
    • じゃないと俯瞰できない
  • メタファはわかりやすいけど危険
  • たとえば、顧客タイプと顧客にわける
    • もうひとつ上のレイヤにわけたりはする
• 17章
  • コードを変更する人間が戦略を理解して、実際に実行する
  • コードを書く人間が意思決定すること
  • 言葉の違いに敏感にry)
  • 「まちづくりの新しい理論」という本が参考になる