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