読者です 読者をやめる 読者になる 読者になる

関西DDD.java スタートアップスペシャル行ってきたのでメモ公開

DDD 開発

kansaiddd.connpass.com

ここ数ヶ月ぐらい前から会社的に今のプロジェクトを改善していきたいね、という話をずっとしていてその中で実践ドメイン駆動設計の社内読書会とかしてたりするんだけど、実際にドメイン駆動設計で開発を進めている人の話が聞きたいな、というところでよいものがあったので行ってきました。前日に「補欠から繰り上がりました」メールが届いていたのをチェックしてなかったら、うっかり行きそびれるところだったけど……

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

ドメイン駆動設計にであって

  • 実践してみた結果
    • 顧客のドメインを掴みにいったつもりになっていた
    • ドメインと出来上がるソフトウェアが一致していなかった
    • 柔軟であるべきところが柔軟でなかった
    • やってみないとわからない
  • 関西DDD.java始動
    • ゆるく
    • DDDとjavaをキーワードに
    • 失敗事例は共有したいなぁ
    • ドメインオブジェクトの永続化を徹底討論する会がやりたい

ドメイン駆動設計の複雑さに立ち向かう

www.slideshare.net

  • 関西のものづくりに対する厚み
    • 神社などを例に
  • 江戸時代にデザインパターン本が!
    • 建築のついて
  • 大工の道具
    • その日の工程によって道具をピックアップしてもっていく
    • 全部持っていくわけではない
    • いつ持って行っても良いようにメンテされている
    • ソフトウェアに似ている

セッション前半

  • そんな人のために
    • 読み解くのが困難
    • 活用に迷う
    • やってみたがうまくいかない

考え方と背景

  • まえがきと結論がいい
    • きちんと読みなおした方がいい
  • ドメイン駆動設計とは
    • 日本語版はお得 => 序文を読もう
    • エヴァンスがどういうことに苦労してきたかという助言
      • どういう効果があるのか
      • 現場の技術者が失敗したことや成功したことから学んだこと
  • エヴァンスの取り組む
  • 想定読者
  • 増田さんはDOA/手続き型/WF系の技術者だった
  • 変化に適応する技術
  • オブジェクト指向の変更容易性
    • 抽象データ型
      • 段階的に人間の発想に近づける
      • intからドメイン層の一級市民を作っていく
      • 人間の目線で見ないと出てこないようなメソッドなどを見つけていくのがドメイン駆動設計
    • モジュラープログラミング
    • メッセージング
      • Javaなどではうまく実現できていない
      • Erlangはよいね
      • 最近の技術はメッセージング志向が強い
  • 適応型のソフトウェア開発
    • 増田さんはアジャイルという言葉はお好きでない
    • 予測型、反復型、適応型
      • そふとうぇあの最終形(着地点)の違い 厳密に定義、それなりに定義、ざっくり定義
      • 反復型は着地点は反復ごとに精緻化していく
      • 適応型は日々更新していく => 最終形は固定するものではない
        • 人間の生活リズムに寄り添っている
  • エクストリームプログラミング
    • 言葉を使った共同作業
    • フィードバック
      • コードを書いて実験することのコストパフォーマンス
    • 必要のない複雑さの持ち込み
      • ベテランになるほど気にかけて欲しい
      • 言葉による意見交換とコードの実験
  • 毎日、方向付け/推敲/作成/移行をおこなう
    • 変化を知覚したら、チームで機敏に反応する
  • エクストリームプログラミング読もう……
  • OO+XP=ドメイン駆動設計?
    • 体験談と焦点の当て方を変えている
  • ドメイン駆動設計の強調点
    • ドメインに焦点
    • モデルとコードの歩調を合わせながら、少しづつ成長させる
      • はじめから合うのではなく、コードを書いてどれだけ合ってるのかチェックして、改善して……
    • 言葉を使ってチームでモデルと設計の改良を続ける
      • ドキュメントではなく言葉を使って(意見交換)
      • コミュニケーションの失敗に関することは本書でたくさんでてくる、そこを乗り越えたところがドメイン駆動設計
  • 俯瞰
    • 第1部はそれ以降に一貫するテーマ 「ドメインモデル」を中心にすべてを組み立てる
    • 第2部は基本スキル(必要but不十分)
      • そのままやっても殆ど役に立たない
      • これをチームで共有したうえで3,4部をやらないと意味が無い
    • 第3部は実際に役に立つモデルを育てる
    • 第4部はつまづきポイントとその対策
      • しっかりやるのは大変だが効果は絶大
    • 少しずつ変化し成長していく様子 1章、7章、8章、13章、15章、結論
    • 失敗したところが大事

セッション後半

第1部

  • 3原則
    • 知識を噛み砕く
    • コミュニケーションと言葉の使用
    • モデルと実装を結びつける
  • どういう意味?
  • ドメイン
    • ソフトウェアを利用する人たちの活動と感心事
    • ドメインでないこと
      • ソフトウェアの開発そのもの
      • コンピュータの仕組みや挙動
      • 画面仕様書やユーザストーリー
    • 理解するために、文脈が必要
      • 活動の目的/背景
      • 例:営業の受注登録 => 月初めと月末の登録は意味合いが違う => 会社にとって月末登録のアラートが
  • ドメインモデリング
    • 利用する人たちの活動と関心ごとを要約する
    • ユーザが持っている関心ごとの中で重要なものを要約する
  • モデル
    • 膨大な知識を要約したシンプルでわかりやすい説明
    • モデリングのスキル「要約力」
    • みんなで本質を要約するといい
  • ドメインモデル
    • ソフトウェアを利用する人たちの活動と関心ごとの本質を簡潔に表したもの
    • 表現
      • 会話
      • スケッチ
      • コード
      • (文章などは補助)
    • あくまでチーム間の意識共有することが必要
  • ユビキタス言語が全てコードにマッピングされていることが重要ではない
  • 第1章
    • 変化と成長の過程を読むのがよい
    • 知識を噛み砕きながら、モデルとコードを少しずつ成長させる
  • 第2章
    • ユビキタス言語
      • いつでもどこでも誰とでも
      • 同じ言葉というところが大事なのではない
      • 技術者が議論するさいに、利用者の関心ごとの言葉が自然に出てくることが重要
      • 要求仕様書と利用者で出てくる同じ言葉は同じ意味ではない
      • 増田さんは言葉が変わってくると違うことを意識している
    • 説明のためのモデル <= このモデルはドメインモデルの話ではない
    • 声に出してモデリングする
      • しゃべりにくい、要点が聞き取れないのはなんらかの問題がある
      • 他の表現との不一致に敏感になる
    • 一つのチームに一つの言語
      • 一つの言語に一つの意味
      • 同じ意味に思える別の言葉に敏感に
      • 第4部の境界づけられたコンテキストや継続的な統合の基本原理
    • 言葉たいせつ
      • エクストリームプログラミングでは、言葉を使った会話がドキュメントがわり
        • ドキュメントは揮発性の内容を残しておくのに重要
        • それがちゃんとチームで共有されていることが重要
  • 第3章
    • ドメイン駆動設計のモデル
      • 初期の分析を支援するだけでなく、設計においても土台になるモデル
    • モデルがユーザにとって重要か?
      • お客さんの関心ごとと開発者の関心ごとが一致しているかのチェック
      • とんでもない勘違いを早めに発見できる
    • 実践的モデラ
      • コードを書く人間が、ドメインの知識を噛み砕き重要な関心ごとを正しく理解するのが最も確実な開発

第2部

  • モデルと実装の一致
    • なかなか一致しない!
    • 作ってる人が頭の中とコードを翻訳しちゃう
    • それをがんばって一致するように改善していくのが大事
  • そのためになにをするのかが書かれているのか、第2部
  • 第2部は基礎練習
    • 単にボールを蹴るのか、ぬかるんだピッチで敵に囲まれた中ボールをけるのか
  • レイヤ化アーキテクチャ
    • ドメインの知識が他の層に入り込んでないかチェックする
    • 意識してやらないとすぐ入り込んでしまう
    • 意識して、ドメイン層に知識をかき集める
    • チームで声を掛け合いながら、ドメイン層にかき集める
  • モデルをコードで表現する工夫
    • エンティティや値オブジェクト
  • 成長を続ける適応型アプローチ
  • 値オブジェクトはメソッドを知識豊かになる
  • エンティティはみつけやすい
    • 太りがち => とことんスリムにする
  • ドメイン層のサービス => 危険!
  • ファーストクラスコレクション
    • ListやSetをラップしたドメインオブジェクト
    • 一覧や履歴という関心ごとの表現手段
    • 複雑なSQLのかわりに、簡単なSQL+メモリ上の操作
  • モジュール(Packages)
  • レポジトリとか
    • オブジェクトのライフサイクルはコードが複雑になりがち
    • モデルの表現から複雑さを取り除く
      • モデルと実装の関係を単純明快に保つ
        • モデルと実装のズレがすぐわかる
      • 別の枠組みでまとめることが上記を行うために必要
    • トランスファインタフェース
      • 通知を表現する
    • 集約が開発単位になる
  • 4〜6章みつつ7章を読むといい
    • 7章の2番め、アプリケーション層を導入するところはチームで共有しておけ
    • ドメイン層の議論を機能視点から隔離する
    • 入出力項目の定義は登場しない
      • ドメイン層の設計にはノイズである
      • 機能的な話にドメイン層の設計が引っ張られてはならない
      • ドメイン層の設計からどういう画面が必要になるか、までいければOK

第3部

  • 実際に役に立つモデル
    • ドメインについて深い理解を表現したモデル
      • 表面的な側面を捨て去る
      • ここに向かうために何をするかというのが、第3部
    • 何をすべきか
  • 8章を読む
    • ブレイクスルーを自分の経験を思い出しながら、読む
  • 第9章はドメイン駆動設計の肝である
    • 暗黙的な概念を明示的にする
    • 概念を掘り起こす努力をしているか
    • ここの徹底なくして深いモデルにたどり着かない
    • プロセス
    • 仕様
      • 述語論理
  • 10章の内容は別の言語で勉強したほうがいい
  • リファクタリングの方向とタイミングを間違えないために
    • すでに動いているコードの根幹を変えるので、選抜チームで取り組む

第4部

  • 局所的でない、長期的という意味で戦略的
  • 意思決定難しい
    • このレベルでも言葉を使った発見と改良に取り組む
    • このレベルでも実装と結びつくモデルを探求する
      • コードを書く人間が中核になる => 分離するとコード書く人に動機づけがない
    • 少しずつ秩序を改善する 少しずつ全体を改善する
  • 蒸留
    • モデルも膨らんでくる => 中核中の中核を見極める「コアドメイン
  • 16章は俯瞰する力をつけるのが重要と言っている

メモ

  • ご多分に漏れず、読み解くのが難しいと感じた一人だったので、今回の内容で色々合点がいきました
    • オブジェクト指向を突き進めた結果というのは、薄々感じてたけど継続して少しずつ改善していくという視点が抜けていたのがよくわかった
  • DDDは設計手法というより考え方
    • 通して増田さんが言っておられたのは「利用者の関心ごとを噛み砕いて知識にする、それを実際にコードを書く人たちがやる」
    • それをチームで共有する
    • 一度に出来ると思わない、継続してモデルとコードを一致していく
  • 一朝一夕で出来るものでなく、少しずつ育てていくイメージ
  • できるところからやる、実験・フィードバックの繰り返し
  • 非常に情熱的なものを感じた、ドメイン駆動設計はエモい