ここ数ヶ月ぐらい前から会社的に今のプロジェクトを改善していきたいね、という話をずっとしていてその中で実践ドメイン駆動設計の社内読書会とかしてたりするんだけど、実際にドメイン駆動設計で開発を進めている人の話が聞きたいな、というところでよいものがあったので行ってきました。前日に「補欠から繰り上がりました」メールが届いていたのをチェックしてなかったら、うっかり行きそびれるところだったけど……
- 作者: Eric Evans
- 出版社/メーカー: 翔泳社
- 発売日: 2013/11/20
- メディア: Kindle版
- この商品を含むブログ (3件) を見る
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (130件) を見る
ドメイン駆動設計にであって
- 実践してみた結果
- 関西DDD.java始動
ドメイン駆動設計の複雑さに立ち向かう
www.slideshare.net
- 関西のものづくりに対する厚み
- 神社などを例に
- 江戸時代にデザインパターン本が！
- 建築のついて
- 大工の道具
- その日の工程によって道具をピックアップしてもっていく
- 全部持っていくわけではない
- いつ持って行っても良いようにメンテされている
- ソフトウェアに似ている
セッション前半
- そんな人のために
- 読み解くのが困難
- 活用に迷う
- やってみたがうまくいかない
考え方と背景
- まえがきと結論がいい
- きちんと読みなおした方がいい
- ドメイン駆動設計とは
- 日本語版はお得 => 序文を読もう
- エヴァンスがどういうことに苦労してきたかという助言
- どういう効果があるのか
- 現場の技術者が失敗したことや成功したことから学んだこと
- エヴァンスの取り組む
- 想定読者
- オブジェクト指向とエクストリームプログラミングにある程度の知識がある技術者
- 上のふたつを実際に適用しようとして、理屈どおりにいかないことを経験した技術者
- 増田さんはDOA/手続き型/WF系の技術者だった
- 上2つに懐疑的
- DDDからオブジェクト指向とエクストリームプログラミングを勉強
- 実践から入って面白さを感じる
- 変化に適応する技術
- オブジェクト指向もエクストリームプログラミングも変更容易性・変更適応性
- 変化に対する技術
- エクストリームプログラミングはオブジェクト指向で生まれ育った
- オブジェクト指向の変更容易性
- 適応型のソフトウェア開発
- 増田さんはアジャイルという言葉はお好きでない
- 予測型、反復型、適応型
- そふとうぇあの最終形（着地点）の違い 厳密に定義、それなりに定義、ざっくり定義
- 反復型は着地点は反復ごとに精緻化していく
- 適応型は日々更新していく => 最終形は固定するものではない
- 人間の生活リズムに寄り添っている
- エクストリームプログラミング
- 言葉を使った共同作業
- フィードバック
- コードを書いて実験することのコストパフォーマンス
- 必要のない複雑さの持ち込み
- ベテランになるほど気にかけて欲しい
- 言葉による意見交換とコードの実験
- 毎日、方向付け/推敲/作成/移行をおこなう
- 変化を知覚したら、チームで機敏に反応する
- エクストリームプログラミング読もう……
- OO+XP=ドメイン駆動設計？
- 体験談と焦点の当て方を変えている
- ドメイン駆動設計の強調点
- 俯瞰
- 第1部はそれ以降に一貫するテーマ 「ドメインモデル」を中心にすべてを組み立てる
- 第2部は基本スキル（必要but不十分）
- そのままやっても殆ど役に立たない
- これをチームで共有したうえで3,4部をやらないと意味が無い
- 第3部は実際に役に立つモデルを育てる
- 第4部はつまづきポイントとその対策
- しっかりやるのは大変だが効果は絶大
- 少しずつ変化し成長していく様子 1章、7章、8章、13章、15章、結論
- 失敗したところが大事
セッション後半
第1部
- 3原則
- 知識を噛み砕く
- コミュニケーションと言葉の使用
- モデルと実装を結びつける
- どういう意味？
- ドメイン
- ドメインのモデリング
- 利用する人たちの活動と関心ごとを要約する
- ユーザが持っている関心ごとの中で重要なものを要約する
- モデル
- 膨大な知識を要約したシンプルでわかりやすい説明
- モデリングのスキル「要約力」
- みんなで本質を要約するといい
- ドメインモデル
- ソフトウェアを利用する人たちの活動と関心ごとの本質を簡潔に表したもの
- 表現
- 会話
- スケッチ
- コード
- （文章などは補助）
- あくまでチーム間の意識共有することが必要
- ユビキタス言語が全てコードにマッピングされていることが重要ではない
- 第1章
- 変化と成長の過程を読むのがよい
- 知識を噛み砕きながら、モデルとコードを少しずつ成長させる
- この結果がドメインモデル
- 第2章
- ユビキタス言語
- いつでもどこでも誰とでも
- 同じ言葉というところが大事なのではない
- 技術者が議論するさいに、利用者の関心ごとの言葉が自然に出てくることが重要
- 要求仕様書と利用者で出てくる同じ言葉は同じ意味ではない
- 増田さんは言葉が変わってくると違うことを意識している
- 説明のためのモデル <= このモデルはドメインモデルの話ではない
- 声に出してモデリングする
- しゃべりにくい、要点が聞き取れないのはなんらかの問題がある
- 他の表現との不一致に敏感になる
- 一つのチームに一つの言語
- 一つの言語に一つの意味
- 同じ意味に思える別の言葉に敏感に
- 第4部の境界づけられたコンテキストや継続的な統合の基本原理
- 言葉たいせつ
- エクストリームプログラミングでは、言葉を使った会話がドキュメントがわり
- ドキュメントは揮発性の内容を残しておくのに重要
- それがちゃんとチームで共有されていることが重要
- エクストリームプログラミングでは、言葉を使った会話がドキュメントがわり
- ユビキタス言語
- 第3章
第2部
- モデルと実装の一致
- なかなか一致しない！
- 作ってる人が頭の中とコードを翻訳しちゃう
- それをがんばって一致するように改善していくのが大事
- そのためになにをするのかが書かれているのか、第2部
- 第2部は基礎練習
- 単にボールを蹴るのか、ぬかるんだピッチで敵に囲まれた中ボールをけるのか
- レイヤ化アーキテクチャ
- モデルをコードで表現する工夫
- エンティティや値オブジェクト
- 成長を続ける適応型アプローチ
- 値オブジェクトはメソッドを知識豊かになる
- エンティティはみつけやすい
- 太りがち => とことんスリムにする
- ドメイン層のサービス => 危険！
- 手続きにドメインの関心ごとが隠蔽しがち
- ファーストクラスコレクション
- モジュール（Packages）
- 重要なモデリング要素
- レポジトリとか
- オブジェクトのライフサイクルはコードが複雑になりがち
- モデルの表現から複雑さを取り除く
- モデルと実装の関係を単純明快に保つ
- モデルと実装のズレがすぐわかる
- 別の枠組みでまとめることが上記を行うために必要
- モデルと実装の関係を単純明快に保つ
- トランスファインタフェース
- 通知を表現する
- 集約が開発単位になる
- 4〜6章みつつ7章を読むといい
第3部
- 実際に役に立つモデル
- 8章を読む
- ブレイクスルーを自分の経験を思い出しながら、読む
- 第9章はドメイン駆動設計の肝である
- 暗黙的な概念を明示的にする
- 概念を掘り起こす努力をしているか
- ここの徹底なくして深いモデルにたどり着かない
- プロセス
- オブジェクト指向は苦手
- イベントストリームやリアクティブ
- 仕様
- 述語論理
- 10章の内容は別の言語で勉強したほうがいい
- リファクタリングの方向とタイミングを間違えないために
- すでに動いているコードの根幹を変えるので、選抜チームで取り組む
第4部
- 局所的でない、長期的という意味で戦略的
- 意思決定難しい
- このレベルでも言葉を使った発見と改良に取り組む
- このレベルでも実装と結びつくモデルを探求する
- コードを書く人間が中核になる => 分離するとコード書く人に動機づけがない
- 少しずつ秩序を改善する 少しずつ全体を改善する
- 蒸留
- 16章は俯瞰する力をつけるのが重要と言っている
メモ
- ご多分に漏れず、読み解くのが難しいと感じた一人だったので、今回の内容で色々合点がいきました
- オブジェクト指向を突き進めた結果というのは、薄々感じてたけど継続して少しずつ改善していくという視点が抜けていたのがよくわかった
- DDDは設計手法というより考え方
- 通して増田さんが言っておられたのは「利用者の関心ごとを噛み砕いて知識にする、それを実際にコードを書く人たちがやる」
- それをチームで共有する
- 一度に出来ると思わない、継続してモデルとコードを一致していく
- 一朝一夕で出来るものでなく、少しずつ育てていくイメージ
- できるところからやる、実験・フィードバックの繰り返し
- 非常に情熱的なものを感じた、ドメイン駆動設計はエモい
