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