3週連続dddその3 ドメイン駆動設計 戦略的設計
TRANSCRIPT
第3週ドメイン駆動設計に戦略的に取り組む
2015年9月16日 増田(@masuda220)
ギルドワークス株式会社 取締役
有限会社システム設計 代表
DDDアライアンス 設立メンバ
3週連続DDD 「ドメイン駆動設計」の要点と実践ノウハウ
アジェンダ
• 戦略的な取り組みの事例
• 基本がたいせつ
• 第14章 モデルの整合性を維持する
• 第15章 蒸留
• 第16章 大規模な構造
• 第17章 戦略をまとめ上げる
• 3週連続DDDのまとめ
• 企業の人材採用/雇用支援システム
• 汎用プロダクトかつ個社対応
– 採用雇用は経営戦略であり企業の独自性が強い
• 会社としての成長とシステムの成長
創業から10年のおつきあい
パートアルバイト領域
パートアルバイト領域
キャリア採用
アパレル特化求人サイト 個社対応
顧客:数百社
挑戦テーマ・深いモデル・しなやかな設計・成長を続ける全体
SBヒューマンキャピタル
• ソフトバンクグループの人材系サービス会社
• 切り口の異なる複数サービス
– 基本は「求人」「職務経歴」「応募」で同じだが…
• 他社サービスを含めさまざまな連携
10年来のおつきあい
モデルの整合性の挑戦ネタの宝庫
• インターネットサービスプロバイダ
• 基幹システム
– レガシー
– 顧客、契約、請求、物流、サポート、…
– キャリア連携/販売チャネル連携
• ドメイン駆動設計で「太陽系戦略」に取組中
現場での支援活動2年継続中
ISP事業の基幹システムでの挑戦現場の問題意識と意欲的な活動勉強になる
取り組みの現実• HRソリューションズ
– システムも事業も実業務にも精通した一人の優秀な技術者と、案件ごとに、改善の取り組み
– 経営が変化とスピードを重視し実践している• システムづくりと運用が超たいへん
• SBヒューマンキャピタル– 短期的な課題、個別の課題解決に忙殺されがち– 現場レベルでの戦略的な取り組み意識の向上から
• ビッグローブ– 戦略的な取り組みの意欲と実践– 時間がかかるだろうが一歩一歩前進中
戦略的に取り組む
• 時間がかかる
• 関係者が多い
• 障害が多い
• すぐには見えない効果
• それでも取り組む動機
• 一歩一歩進む
• 基本に忠実に
ものづくり屋の本能良いもの、役に立つものをつくりたいビジネス上の期待に応える
誰がやるのか
• 意思決定と行動
– 開発チーム/現場の技術者
– 複数の開発チーム
• どうやって
– 言葉を使った意図の伝達
– さまざまな力関係とトレードオフの判断
• そのための膨大な知識の理解と整理
– 戦略を「コード」で表現する
「基本」を戦略的に実践する
• 「オブジェクト指向」を戦略的に
• 「エクストリームプログラミング」を戦略的に
• 第1部の「三原則」を戦略的に
• 第2部の「基本スキル」を戦略的に
• 第3部の「深いモデルの探求」を戦略的に
オブジェクト指向と「変更容易性」
• 抽象データ型/段階的抽象化
– プログラムを人間の発想に近づけると扱いやすい
• モジュラープログラミング
– 独立性の高い部品に分けると扱いやすい
• メッセージング
– 部品の組合せ型が柔軟だと扱いやすい
どのパラダイムにも共通する設計の考え方ドメイン層のコードは、たぶん似たものになる
LocalDate
日付を汎用的に扱う手段Java APIのレイヤ
int yearshort monthshort day
LocalDateの内部Java言語仕様のレイヤ
if( day > 31 ) …
DateOfBirth
「誕生日」に用途を限定した独自定義クラス「ドメイン層」の一級市民(ドメインオブジェクト)人間の発想
コンピュータの仕組み
抽象データ型/段階的な抽象化コードを人間の発想に近づける
Boolean 今月が誕生月()Days 誕生日まであと何日()
plusDays()plusMonths()
「モジュール化」と「メッセージング」
受付役
仲介役
回答役
経路情報専門家
判定役
おーい手伝って
後はまかせた
おーい考えて
おーい教えて
教えて
最短経路は…
独立性の高い部品
独立性の高い部品
独立性の高い部品
独立性の高い部品
独立性の高い部品
人間の営みと同じ仕組み必要に応じて最適チームを結成
「適応型」のソフトウェア開発開発のスタイル
方法論ソフトウェアの最終形(着地点)
開発サイクル
予測型ウォータフォール
事前に定義厳密に定義
固定分析/設計/製造
反復・漸進型
RUPそれなりに定義
反復ごとに精緻化
方向付/推敲/作成/移行
各フェーズで分析/設計/製造を、N回「反復」する
適応型XP
スクラムざっくりと定義
日々更新日、週、春夏秋冬
(人間の生活リズム)
ソフトウェアの開発スタイル• 「変更」との戦いの歴史
– 変更のコストとの戦い
– 変更のリスクとの戦い
• 「エクストリームプログラミング」は、積極的に「変化を目指す」開発スタイル
変更を管理する
変更を受入れる
変化を目指す
予測型 反復・漸進型 適応型
変化を目指す開発チーム• コミュニケーション
– 言葉を使って意図を伝える
• シンプリシティ– 複雑になるほど変化が難しくなることを知っている
• フィードバック– 経験/実験にもとづき進むべき道を探す
• 勇気– 行動する勇気、耐える勇気
• リスペクト– お互いの考えと行動に関心を持ち、かつ、尊重する
戦略的に取り組む
• 「オブジェクト指向」の変更容易性をより広く、より長期に
• 「エクストリームプログラミング」の適応型の開発をより広く、より長期に
第4部 戦略的設計に取組みながら、ここの理解と実践力を鍛える
より広く、より長期に
第2章言葉を使った意図の伝達
第1章ドメインの知識をかみ砕く
第3章モデルと実装を結びつける
ドメインモデル
ドメインの膨大な情報をかみ砕き、蒸留して重要な関心事を鋭く説明する
選び抜かれたドメインの重要な関心事をコードで表現する
会話を繰り返して「要約」を改善する(重要点を明確にする)
「重要な語彙」をメンバーで合意する/共有する
モデル• 膨大な知識を「要約」したシンプルでわかりやすい説明
• モデリングのスキル=「要約力」
–重要な要素を発見する力
–本質的でないものを削る力
–厳密に組み立てる力本質的でないものを削る力がほんとうに重要議論と行動が迷走しないために
3つの原則を戦略的に
• 第1章 知識をかみ砕く
– 戦略的な意思決定をし、適切に行動するためには、膨大な知識が必要
• 第2章 言葉を使う
– 戦略的な意思決定も、開発チームのメンバーの「言葉」を使ったコミュニケーションが基本
• 第3章 モデルと実装を結びつける
– 戦略も、コードで表現する
第2部を広い範囲で長期的に
• 利用する人たちの関心事を隔離する– 「ドメイン層」
• 利用する人たちの関心事を「抽出」し「コード」で表現する– 「ドメインオブジェクト」
• 関心事の「モデル」(要約)に集中する– 機能視点で駆動しない
– データベース視点で駆動しない
– 画面視点で駆動しない
機能/データベース/画面の中核にある「関心事のモデル」を探す
概念を掘り出す努力していますか?
• 言葉に耳を傾ける
• ぎこちなさを精査する
• 矛盾について熟考する
• 文献を読む
• 何度でも挑戦する
ドメイン駆動設計の実践のキモこれを広い視野で、より複雑な問題を対象に長期的に実践するのが戦略的な設計の基本9章を読みながら、個人やチームで振り返りを
多くのメンバー/チームの日常の習慣になってくるとその集積が戦略的に効いてくる
深いモデル/しなやかな設計
• ドメイン層のごく一部での取り組み
• ドメイン層全体に波及する
– 業務知識を要約し鋭く説明できる力
– ソフトウェアの変更容易性を向上するテクニック
• システム全体に波及する– プレゼンテーション層/アプリケーション層/データソース層
• 連携するシステム全てに波及する
チームの全員の考え方と行動に波及するすべての関係者の考え方と行動に波及する
第14章の概要
• 境界づけられたコンテキスト
• 継続的な統合
• コンテキストマップ
• 境界づけられたコンテキスト間の関係
• 象のモデルを統一する
• モデルコンテキスト戦略を選択する
• 関係を変更していく
境界づけられたコンテキスト
大きな部品を特定する
• 一つのモデルとして独立していそうな範囲
– 開発チーム
– 運用チーム
– コードベース
– データベーススキーマ…
• ひとつのモデルが適用できる範囲の制限
• モデルの一貫性を保つ努力をする範囲の限定
• チームの「言葉」の通用する範囲に注目する
これらが分かれているが、1つのモデルということはないひとつの範囲に複数のモデルが生まれてしまうことはある
ひとつのコンテキスト内で継続的な統合をする
• チーム内(境界づけられたコンテキスト内)の「一貫性」を維持する
• 「概念」は、別々の人の頭の中でばらばらに進化をはじめることに、いつも注意する
• コードの統合に成功しても、「理解」が統合できていないリスクを気に掛ける
• 複数のコンテキスト間の関係を扱いやすくするための前提
コンテキストマップ
コンテキストコンテキスト
コンテキスト
モデル
モデル
モデル
「ドメイン層」の「モデル」間の関係現実がどうなっているかを知る
関係者でスケッチしてみると「気づき」が多く、非常に効果的季節単位くらいに繰り返したい
コンテキスト間の関係
別々の道
チームのコミュニケーションの意欲と能力
関連するシステムに対する制御
腐敗防止層
順応者
顧客/供給者チーム
公開ホストサービス
共有カーネル
単一の境界づけられた
コンテキスト
共同経営
現実を直視なぜそうなっているかを理解する
第14章の要点
• 現実を直視する
– 関係者で共通の理解に
– 背景や歴史まで視野を広げて
– ある種の「美しさ」
• 開発チームによる意思決定と行動
– チーム内
– チーム間
• 統合による利益と調整コストのトレードオフ
密接な関係を実現する
• 複数のコンテキスト(チーム)を単一のコンテキスト(チーム)に統合にする
• 共同経営
• 共有カーネル(複数チームで共同開発)
密接な関係のメリット密接な関係のコスト短期・長期局所・全体
明確な関係を打ち立てる
• 顧客/供給者のチーム
• 公開ホストサービス
• 公表された言語
関係を確立するメリット関係を維持するコスト短期・長期局所・全体
コミュニケーションしながらどこかに合わせる
戦略を選択する時の考えどころ
• チームでの意思決定と、より上層での意思決定• コンテキストに自らの身を置く• 境界を変換する• 変更できないものを受入れる• 外部システムとの関係• 設計中のシステム• 別のモデルの特殊な要求を満たす• デプロイ• トレードオフ• すでにプロジェクトが進行中の場合
「現実の直視」「トレードオフ」
「実践的な判断」熟読すべし
関係者で議論すべし
page.391~398
変換(関係を変えていく)• コンテキストをマージする
– 別々の道 ⇒ 共有カーネル
– 共有カーネル ⇒ 継続的な統合
• レガシーシステムを段階的に廃止する
• 公開ホストサービス ⇒ 公表された言語
「現実の直視」「トレードオフ」
「実践的な判断」熟読すべし
関係者で議論すべし
page.398~404
第14章 まとめ
• ひとつのコンテキスト内部のモデルの一貫性を維持する
• 現実のコンテキストマップを作る
• コンテキスト間の選択肢を共通理解にする
• 現実を直視する
• トレードオフを考える
• 関係者で活発に意見交換する
関係者の活発な意見交換がすべての戦略的設計の前提「意思決定」を、必ず「コード」で表現すること
第15章の概要• コアドメイン• 蒸留の拡大• 汎用サブドメイン• ドメインビジョン声明文• 強調されたコア• 凝集されたメカニズム• 蒸留して宣言スタイルにする• 隔離したコア• 抽象化されたコア• 深いモデルの蒸留• リファクタリングの対象を選ぶ
中核中の中核を見究める• 中心になる問題に集中し、枝葉末節の海でおぼ
れないようにする– 「ドメインモデル」自体が、重要な関心事のかたまり
– 「ドメインモデル」が複雑になってきた時に、さらに、その「中核」部分を見究める活動
– 高度な「要約力」
– すこしずつ、実験とフィードバックを繰り返しながら「コアドメイン」を識別していく
• ビジネスへの影響の大きさ/ソフトウェアの価値– 「第1章 知識をかみ砕く」を高度に実践する
かたまりを「抽出」する
• 「汎用サブドメイン」
– 独立性が高く、一般的な業務知識などをたよりに発見できる「かたまり」
• 「凝集されたメカニズム」
– 技術的な関心事の隠ぺいを追求することで発見できる「かたまり」
– 「意図の明白なインタフェース」のみ公開する
「かたまり」の「意図」を明確に
• 名前
• 「かたまり」間の依存関係
• 「言葉」を使って「名前」と「関係」の検証と改良を続ける
– AはBを使う
– AはBに依存する
– AはBを詳細化する…
「関係」をもっと知識豊富な言葉に
「ドメインビジョン声明文」• 言葉を使って「コアドメイン」を表現してみる
• 費用対効果が高い– 簡単に取り掛かれる
– 簡単に複数案を作れる
– 簡単に変更できる
• チームが根本概念を共有する効果
• 正しく表現する– 語尾をあいまいにしない
– だらだら語らない
– 「あれ」「これ」「それ」を使わない
– 「カタカナ言葉」を使わない
「強調されたコア」• 実装は変更しない
• 既存の「モデル」で重要な点を強調
– 本質的なオブジェクトを書きだしたり要約図を描いてみる
– ドキュメントがあれば、付箋やマーキングで強調してみる
• ラフスケッチと「意見交換」
– 強調した点を「正しく」表現してみる
• チームで「主要な関心事」を共有する手段
「隔離されたコア」• コードを実際に変える
• 重要な要素を、特定のモジュールに集める
• リファクタリング– モジュール構成
– モジュール名
– クラス名
– メソッド名/引数の型/返す型…
• 深いモデルをコードに反映
• しなやかな設計にして変更に機敏に対応
「抽象化されたコア」• 根本的な概念を、クラスやインタフェース宣言
に「抽出」する
• 他の詳細は、この抽象化されたコアに依存するように設計する
• 根本の概念は安定しているが、詳細の変更が頻繁に発生する時に、効果を発揮する
「深いモデル」の探求の帰結「しなやかな設計」の追求の帰結
第15章 まとめ
• 「中核の関心事」を、「コード」を書く人間が的確に理解する効果
• 「中核」の関心事を、「コード」で表現する威力
• 少しずつ地道な改善活動– 「チーム」で続ける
– 大勢で、長期的に
– 協力のための手段「言葉」
– 「第3部 深い洞察に向かうリファクタリング」の高度な実践
第16章の概要
• 進化する秩序
• システムのメタファ
• 責務のレイヤ
• 知識レベル
• 着脱可能コンポーネントフレームワーク
• 構造による制約にどの程度厳しくすべきか
• ふさわしい構造への「リファクタリング」
主題:「森を見る」力をつける
• コードに責任を持つ開発者たちが、「全体を俯瞰」し理解する効果
• 大きく複雑なシステムの「秩序」を少しずつ改善していくための手掛りの発見
• 関係者が全体の構造を理解し議論するための「枠組み」を手に入れる効果
メタファー
• チーム内の共通理解に強力な武器になることがある
• 「わかったつもり」で、実際には異なる理解になる危険性も高い
• 「カタカナ」は厳禁
• 「キャッチフレーズ」は厳禁
• いつでも、だれでも同じ言い回しになる「言葉」であること
責務のレイヤ• モジュール(独立性の高い部品)の抽出が前提• モジュール間の「依存関係」に注目して整理する• 候補
– 意思決定– ポリシー– 確約(コミットメント)– 業務(オペレーション/トランザクション)– 潜在能力(リソース)
• 始めは、上下2層にわけることから– 層が多いことが役に立つわけではない
• 参照の方向性を一方向に限定する実験は効果的
最初は不自然な設計に見えるが、ブレークスルーのきっかになることがある
役に立つ着眼点• 時間軸での依存関係
– 先に存在すべきオブジェクト
• 変更の理由/変化のサイクル– 頻繁で継続的/短い イベント系
– 時々/ゆっくり リソース系
– ほぼ固定 制度
• 「責任分界点」とそれぞれの「責任」– 契約/利用規約
– 職務分掌規程
• 「依頼役」と「サービス提供役」
比較的、体系的に学べる
「知識レベル」
• 判断ロジックがごちゃごちゃしたり、置き場所に迷う時
• 簡単な実験
– XxxType と Xxx に分けてみる
– 例:従業員タイプと従業員
• 「レイヤ構造」ではない
– 参照を一方向に限定する必要はない
16章のパターンへのコメント
• メタファ– わかりやすいが危険
• 責務のレイヤ– 分析により比較的、論理的に発見できる– データモデリングなどの考え方と手法も参考になる
• 知識レベル– 判断ロジックがごちゃごちゃしたり、置き場所に迷う時
• 着脱可能なコンポーネントフレームワーク– ここまで熟成している間に環境がかわってしまう?– 適応型の開発スタイルでは、目的地ではなく結果
ふさわしい構造へのリファクタリング
• ミニマリズム– いちどに大きく取り組まない
• コミュニケーションと自己規律– ドキュメントでは一貫性は維持できない
– チームの通常の会話では、全体の構造を共有できない(視野の経験の差が大きい)
– 「戦略」を「言葉」と「コード」で表現する
• 繰り返し形を変えることでしなやかな設計になる
• 継続的な蒸留(補助的な構造の削除)による負荷の軽減
設計の改善
第16章のまとめ• モデルが大きく複雑になってきたときの整理の
考え方とやり方
• ビジネスモデリングやアナリシスパターンの文献から学べることも多い
• 蒸留(深いモデルの探求)とリファクタリング(しなやかな設計の追求)を、広い範囲で、長期的に取り組むための手段
第17章の概要
• 「大規模な構造」と「境界づけられたコンテキスト」を組み合わせる
• 「大規模な構造」と「蒸留を組み合わせる」
• まず評価する
• 誰が戦略を決定するのか
• 戦略的設計の「意思決定」を行うために欠かせない6つのこと
戦略的な設計に取り組むためにはまず現状を正しく把握する
• コンテキストマップを描くこと
– あいまいな点や怪しいところを発見する
• 「言葉」の使われ方を評価する
• 何が重要であるかの理解度
• モデル駆動設計に向いた技術を使っているか
• 開発者の技術スキル
• 開発者のドメインへの「関心」の度合い
さまざまな厳しい現実と誠実に向き合う
誰が戦略を策定するのか
• エクストリームプログラミングの「アーキテクト」
– 通常はプログラムタスクを担当する開発者
• 「ドメイン層」を開発するチームから、システムの全体的な構造が現れる
– 全体的な構造も「ドメインモデル」が駆動する
• 「アプリケーション開発チーム」に貢献する「アーキテクチャチーム」
最初から優れたアーキテクトはいない現場で、実践の中で才能を見出し、育てて行く。(自分も含めて)
戦略設計上の意思決定かかせない6つのこと
• 意思決定はチーム全体に伝える
• 意思決定のプロセスにフィードバックを組み込む
• 計画は変化し進化を続ける
• アーキテクチャチームが優秀な人材を吸い上げてはいけない
• ミニマリズムと謙虚さ
• オブジェクトはスペシャリスト、開発者はジェネラリスト
第17章へのコメント
• コードを変更する人間が「戦略」を理解し、実行に移すことがもっとも効果的
• 「戦略」も「言葉」による意図の伝達と実験が基本
– 多くの人たちが長期的に取り組むための武器
• 変化に対応し、少しずつ成長を続ける全体
– 「適応型」の開発スタイル
– 「戦略」こそ「日々」の変化の積み重ね
– 進化を続ける「有機的な秩序」
– 「まちづくりの新しい理論」
第3週「戦略的な設計」のまとめ
• 基本たいせつ– オブジェクト指向 エクストリームプログラミング
– 第1部の3原則(知識・言葉・コード)
– 第2部のモデルと実装を結びつける基本スキル
– 第3部の深いモデルの探求としなやか設計の追求
• 第14章 境界と関係を明確にする
• 第15章 「中核」に焦点をあてる
• 第16章 大きな単位のモジュール化/依存関係
• 第17章 進化する秩序、成長する全体
「ドメイン駆動設計」とは
厳しい現実の中で、ソフトウェア設計を習得しようと奮闘してきた技術者の物語。
不完全な状況の中で、抽象的な設計原則を、現実のソフトウェアに適用するための助言。
「日本語版への序文」 by エリック・エヴァンス
エヴァンスは、ソフトウェア開発の成功も失敗も味わってきた。この本は、エヴァンスが成功と失敗の両方から学んだ教訓を伝えている。
「序文」 by マーチン・ファウラー
• どんな状況でも改善できる
• どんなときでも「あなた」から改善を始められる
• どんなときでも「今日」から改善を始められる
エクストリームプログラミングの「はじめに」に記されたケント・ベックのメッセージ
【広告】DDDの3原則を体験的に学ぶ
• 【DDD Alliance】第2回 実践的ドメイン駆動設計ワークショップ
• http://ddd-alliance0002.peatix.com
• 9月26日(土)と10月3日(土)の2日コース
• 有償(1万5千円 税抜)
• 内容– 「要約力」
– 「ドメインの創造的な学び方」
– 「言葉」を使ったモデリングと設計の体験学習