Download as PDF, PPTX
Uploaded by増田 亨
PDF, PPTX14,865 views
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第３部)
エヴァンスのドメイン駆動設計 「第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
Viewers also liked
Similar to 3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第３部)
More from 増田 亨
3週連続DDDその2 深いモデルの探求(ドメイン駆動設計 第３部)
- 1.第２週深いモデルの探求2015年9月4日 増田(@masuda220)ギルドワークス株式会社 取締役有限会社システム設計代表DDDアライアンス 設立メンバ３週連続ＤＤＤ 「ドメイン駆動設計」の要点と実践ノウハウ
- 2.
- 3.アジェンダ• 第１週のおさらい– 考え方–第１部 ドメインモデルを機能させる– 第２部 モデル駆動設計の構成要素• 第２週のテーマ– 第３部 より深い洞察へ向かうリファクタリング
- 4.
- 5.
- 6.
- 7.LocalDateクラス日付を汎用的に扱う手段Java APIのレイヤint yearshortmonthshort dayLocalDateの内部Java言語仕様のレイヤif( day > 31 ) …DateOfBirthクラス「誕生日」に用途を限定した独自定義クラス「ドメイン層」の一級市民（ドメインオブジェクト）人間の発想コンピュータの仕組み抽象データ型／段階的な抽象化人間の発想に近づけるBoolean 今月が誕生月()Days 誕生日まであと何日()plusDays()plusMonths()
- 8.
- 9.俯瞰• 第１部 ドメインモデルを機能させる「ドメインモデル」を中心にすべてを組み立てる第２部/第３部/第４部に一貫するテーマ•第２部 モデル駆動設計の構成要素基本スキル（第３部と第４部の土台づくり）このレベルは「必要」そして「不十分」• 第３部 より深い洞察へ向かうリファクタリング実際に「役に立つモデル」を育てる• 第４部 戦略的設計より広い範囲で、より長期的に取り組む
- 10.
- 11.
- 12.ドメイン• ソフトウェアを利用する人たちの「活動」と「関心事」– ソフトウェアの利用は、活動全体の一部–関心事の焦点は、ビジネスや業務上の成果• ドメインではないこと– ソフトウェアを作る活動そのもの– コンピュータの仕組みや挙動– 画面仕様書/機能一覧/ユーザーストーリー/…
- 13.
- 14.
- 15.第１章 知識をかみ砕く• 「モデル」の成長する様子•コードでも表現してみる• 本質的な関心事を探す• 継続的に学ぶ• 知識をかみ砕いた成果が「ドメインモデル」– 利用する人たちの「活動」と「関心事」の本質を「簡潔」に表現した言葉・図・コード
- 16.
- 17.
- 18.言葉たいせつ• 「エクストリームプログラミング」では、言葉を使った会話がドキュメントの代わり• 「言葉」は、そのままクラス／メソッド／パッケージの候補•あらゆる場所で同じ言葉を– 会話/チャット/メール/コミットログ/ソースコード– 早期に食い違いを発見する
- 19.第３章モデルと実装を結びつける• ドメインの理解にも、コードの設計にも役に立つ「モデル」（要約）を探す• 「モデル」と一致した「コードの骨格」は利用者にも理解できる•コードを書く人間がドメインを深く理解するのが、もっとも確実でもっとも効果的なソフトウェア開発手法
- 20.
- 21.【広告】DDDの３原則を体験的に学ぶ• 【DDD Alliance】第2回実践的ドメイン駆動設計ワークショップ• http://ddd-alliance0002.peatix.com• ９月２６日（土）と１０月３日（土）の２日コース• 有償（１万５千円 税抜）• 内容– 「要約力」– 「ドメインの創造的な学び方」– 「言葉」を使ったモデリングと設計の体験学習
- 22.
- 23.主題：モデルと実装の協調を保つ• 第４章 ドメインを隔離する•第５章 ソフトウェアで表現されたモデル• 第６章 ドメインオブジェクトのライフサイクル• 第７章 言語を使用する：応用例
- 24.主題：モデルと実装の一致• 非常に難しい– 頭の中の理解がコードで表現できていない–そこに気づかない• 無意識で高速な翻訳能力• モデルとコードの不一致– 的はずれなソフトウェア– 構造がねじれたソフトウェア– 変更コストの増大⇒成功が止まる⇒変化に適応できない• 何をすべきか– ドメインの隔離の徹底– モデルをコードで表現する基本の徹底– ドメインオブジェクトのライフサイクルの複雑の分離
- 25.
- 26.第４章 ドメインを隔離する• 形式的なコーディングルールや、フレームワークの導入は隔離の「出発点」•ちょっとした修正で、ドメインの知識がドメイン層以外に拡散する危険を察知する嗅覚を磨く• プレゼンテーション層からドメインロジックを抽出してドメイン層に移動し続ける• データソース層からドメインロジックを抽出してドメイン層に移動し続ける
- 27.
- 28.第５章ソフトウェアで表現されたモデル• 「モデル」（利用者の主要な関心事）をプログラムで表現する• 「モデル」と「実装」の一致は難しい•そのための基本スキルを体で覚える• 第３部と第４部の土台– ほんとうに役に立つのは深いモデルを見つけた時– 大きな効果がでるのは戦略的に取り組んだ時
- 29.第６章ドメインオブジェクトのライフサイクル• ドメインオブジェクトのライフサイクル管理はコードを複雑にする• 「モデル」の表現から、この複雑さを取り除く•「集約」単位で関心事の境界を明確にする• 「集約」は実装の単位でもある
- 30.第７章 より実戦に近い練習• 「モデル」と「実装」が育っていく過程とリズム•「モデル駆動」で設計するということ– 最初に「アプリケーション層」を導入する• 「ドメイン層」の議論を「機能」視点から隔離する• 機能（処理）の詳細化からの設計ではない– 入出力項目（画面帳票）の定義は登場しない• プレゼンテーション層無しのドメイン層の設計と実装– データモデル／テーブル設計は登場しない• データモデルから独立したドメイン層の設計と実装
- 31.第２部は基礎練習• ボールを蹴って止める基本の練習• 相手に囲まれても確実にできる•９０分走りぬいたあとでも確実できる• ぬかるんだピッチでも確実にできる• 第２部の内容をどんな状況でも、確実に使えることが、「第３部 深いモデル」、「第４部戦略的設計」を実践する土台になる。
- 32.
- 33.主題：実際に役に立つモデルを探す• 第８章 ブレークスルー•第９章 暗黙的な概念を明示的にする• 第10章 しなやかな設計• 第11章 アナリシスパターンを適用する• 第12章 デザインパターンをモデルに関係づける• 第13章 より深い洞察に向かうリファクタリング
- 34.
- 35.
- 36.役に立つモデル• ドメインについての深い理解を表現したモデル– 利用者の「主要な関心事」の「明快な表現」–表面的な側面を捨て去る– 利用する人たちの要望に機敏に対応できる• 何をすべきか– 「深いモデル」を目指した「リファクタリング」– 「言葉」を使った発見／実験／改良– 実験と成長のための「しなやかな設計」の工夫
- 37.
- 38.コードのいやな臭い• 重複したコード– ドメインの一つの関心事を、複数個所に書いている•長いメソッド– ドメインの概念が手続きの中に埋没している• 巨大なクラス– 概念の「抽出」が不十分（暗黙になっている）• 長すぎる引数リスト– 用途がはっきりしないメソッド
- 39.「分割」ではなく「抽出」• 長いメソッド– 長いメソッドの「分割」ではなく–意味のあるコードのかたまりをメソッドに「抽出」• 巨大なクラス– 巨大なクラスの「分割」ではなく– 関連性が強いインスタンス変数とロジックを発見してクラスとして「抽出」• クラスの多いパッケージ– パッケージの「分割」ではなく– 意味のあるクラスのグループを発見して「抽出」• 「抽出」– 意味のあるかたまりを見つける– 名前をつける– 独立させる
- 40.深いモデル• ドメインエキスパートの主要な関心事と、それに深く関連した知識を明快に表現する– 主要な関心事–それに深く関係した知識• ドメインの表面的な側面を捨て去る• 「モデル」は、全体のごく一部– 膨大なドメインの知識を蒸留した本質的な部分– ユビキタス言語の中で骨格になる重要な言葉– ドメイン層のソースコードの「核」
- 41.深いモデル／しなやかな設計• 「言葉」や「ラフスケッチ」によるモデリングは、非常に柔軟で、いろいろな実験が簡単にできる• 「コード」の組み換えは、コストが高く、リスクも大きい•「モデル」と「コード」を一致させながら、「モデル」の実験をやりやすくするためには、「コード」のしやなかさが必須– ソフトウェア設計スキルの見せ所– しやなかにするために「リファクタリング」し、その結果さらに「リファクタリング」がやりなすくなる
- 42.「モデル」の発見のプロセス• 「役に立つモデル」は、開発のプロセスの中で発見していく• 「モデル」は、ドメインを理解するための「手段」であると同時に、コードの設計図でもある–オブジェクト指向らしいアプローチ• コードを書くことが重要なフィードバック– 「言葉」や「図」で表現したモデルの具体性と論理性を検証する良い手段
- 43.第８章 ブレークスルー• ブレークスルーの体験談–悪くないモデルなのだが– ブレークスルー 「シェア」と「シェアパイ」– さらに深いモデル– 冷静な意思決定– 結末• 好機• 基本への集中• エピローグ：新しい洞察の連鎖
- 44.「８章 ブレークスルー」を読む• ブレークスルーの自分の経験を思い出す–なんだ、こういうことか– お、そうか– 目からうろこ• 変化のリズム– 緩－緩－急、緩ー緩ー急、…• 「緩」 は基本を地道に繰り返し、小さな変化を積み重ねる期間• 「急」 は大きな変化に冷静に対処する期間• 大きな変化の時– 「発見の喜び」と「実験」と「実装」を冷静に制御する– チームで納得して行動する
- 45.シェアとシェアパイ• 融資団（シンジケート）– 複数の金融機関が共同して融資する•限度額– 最大の貸し出し金額– シンジケートの金融機関ごとの限度額の合計– 金融機関ごとの「分担比率（シェア）」が決まる• 貸出– 一回の貸し出し– 貸出ごとに金融機関の「分担比率（シェア）」が決まる• 限度額の「分担比率」と、貸出の「分担比率」の関係がブレークスルーポイントになった話
- 46.兆候と結末• 兆候（１９８ページ）– ルールの追加や変更に対応できる程度には、良いコードになっていた–さまざまな取引ルールが明らかになるにつれ、コードの複雑さが増し、しだいにルールの追加変更にかかる時間が増えていった– 丸めによっておこる微妙な不整合– これほど「苦労」するのは、基本的に設計に問題がある兆候ではないか？• 結末（２０４ページ）– 自分たちを当惑させる予期せぬ要求変更が飛び出さなくなった– 丸めのロジックは、（複雑だが）安定し、わかりやすくなった– 「シェアパイ」が次期バージョンの基本コンセプトになり、製品の営業トークにも使われるようになった
- 47.第８章 まとめ• リファクタリング（設計改善）で、コードをきれいに保つ–それなりに、良いコードになっている手ごたえが前提• それでも、じわじわと増大する複雑さや、変更依頼とコードとのギャップへの気づき– ブレークスルーの兆候• 突然のブレークスルー– 突破口の発見/実験/適用• 製品コンセプトや営業活動への波及• 新しい洞察の連鎖– このブレークスルーでコードがきれいになったことで、隠されていた別のコードの複雑さが明らかになり、新たなブレークスルーにつながった
- 48.第９章 暗黙的な概念を明示的にする• 概念を掘り出す–言葉に耳を傾ける– ぎこちなさを精査する– 矛盾について熟考する– 文献を読む– 何度でも挑戦する• それほど明確でない概念をモデル化する方法– 明示的な制約– ドメインオブジェクトとしてのプロセス• 仕様(Specification)
- 49.「概念」を掘り出し表現する手段• 長いメソッドに隠された概念– 意味のあるコードのかたまりを見つけ、メソッドに「抽出」•巨大なクラスに隠された概念– 関連性が強いインスタンス変数とロジックを発見して、クラスに「抽出」• クラスの多いパッケージに隠された概念– 意味のあるクラスのグループを発見して「抽出」• 「抽出」– 意味のあるかたまりを見つける– 名前をつける– 独立させる
- 50.概念を掘り出す努力していますか？• 言葉に耳を傾ける• ぎこちなさを精査する•矛盾について熟考する• 文献を読む• 何度でも挑戦するドメイン駆動設計の実践のキモ９章を読みながら、個人やチームで振り返りを
- 51.言葉に耳を傾ける• 利用者の活動や関心事を知る人（ドメインエキスパート）との会話– 聞き取れない言葉–自分の理解となにかが違っていそうな違和感– 自分が想定して言葉とは別の言葉による回答– 会話（Ｑ＆Ａ）のかみあわなさ– 相手の怪訝な顔– 会話の一瞬の間• すべて、重要な「概念」を発見できる手掛り
- 52.ぎこちなさを精査する• 「欠けている概念」の兆候– 複雑な処理（長いメソッド）–いろいろな用途に使われるクラス（巨大なクラス）– 新しい要求がでてくるたびに、コードが複雑になる箇所• if/else の追加• for 内への if 文の追加• この兆候を見つけたら– その「複雑さ」への懸念を、「ドメインの言葉」で語ってみる– 相手は、開発者仲間でも良いし、ドメインエキスパートへの画面の説明でも良い– 「ドメイン言葉」を使って、声に出すことが重要
- 53.矛盾について熟考する• 兆候– ドメインエキスパートが、時と場合によって、矛盾することをいっているように感じる–複数のドメインエキスパートの言葉が、矛盾しているように感じる– そこに「未知の概念」が隠れている可能性を考える• 考える– すべての兆候を熟考できるわけではない– すべての兆候に鈍感になると「概念」の「掘り出し」の機会を失う– 「少しは考えてみる（時間がきたらあきらめる）」を習慣に– 「矛盾」を感じたことは記憶しておくあとで「概念」を掘り出せた時の学びが増える
- 54.文献を読む• 「概念」を探す時の良い手がかり– その分野の基本的な概念の解説書（入門書）–ビジネスの一般常識• 契約• 会計• ビジネス文書の書き方• 全体像、主要な要素、その関係を表現した箇所に、注目すると効率的– 目次（全体の構造）– はじめに（概要説明）– 図・表– 用語集
- 55.何度でも挑戦する• 手掛りは些細なことばかり– 会話の違和感–矛盾– コードの漠然としたごちゃごちゃ感• こういうことを手掛かりに、「こうやったらどうなる」「こう考えたらどうなる」を繰り返す– 回数を繰り返すことが「概念」を発見する基本– 「考えてみたがわからない」を繰り返すのが良いこと
- 56.概念を掘り出す努力していますか？• 言葉に耳を傾ける• ぎこちなさを精査する•矛盾について熟考する• 文献を読む• 何度でも挑戦するドメイン駆動設計の実践のキモ９章を読みながら、個人やチームで振り返りを
- 57.９章の補足• 「制約」• 「プロセス」•「仕様」 (Specification)
- 58.９章の補足：制約• 制約が「概念」の発見の手掛りになる• 制約のなさに「便利さ」ではなく「気持ち悪さ」を感じよう–String– LocalDate– BigDecimal– Collection…
- 59.９章の補足：「プロセス」• オブジェクト指向では表現しにくい概念• イベントストリームやリアクティブの考え方が武器になる–利用者の関心事を表現する武器– 「手順」としてのイベントストリーム– 「状態」の扱い方としてのリアクティブ
- 60.９章の補足：「仕様」• 仕様(Specification)– 述語論理(AND/OR/NOT/EXIST/…)をオブジェクト指向的に表現しようとした試み–オブジェクト指向の苦手な世界– Prologやデータ正規化の考え方が参考になる• 論理型パラダイムとか、ルールエンジンとか「ドメイン駆動設計」の中で繰り返し登場するテーマ• 良い実装の仕組みがあれば強力な武器になる• 利用者の関心事を表現する武器として
- 61.第10章 しなやかな設計• 意図の明白なインタフェース•副作用のない関数• 表明• 概念の輪郭• 独立したクラス• 閉じた操作• 宣言的な設計• 設計の宣言的スタイル• 攻める角度開発者が「ソフトウェアを利用する人たちの関心事」に集中するための工夫
- 62.意図の明白なインタフェース• クラス、操作（メソッド）、パッケージの名前– 利用する人の関心事をそのまま表現した名前•実装を隠す– 名前からデータ処理の詳細（how）を消す– ドメインの関心事を語る言葉と、コンピュータの処理を語る言葉を明確に分離する• ドメイン層のメソッドの引数の型と返す型– メソッドの引数はドメインオブジェクトの型を使う– メソッドが返す型はドメインオブジェクトの型を使う– 値オブジェクトの重要な用途• そうすることで「利用する人たちの関心事」を考えている時に、実装の心配事を脇に置いておけるようになる
- 63.値オブジェクト（10章の実践）• 独立したクラス– 言語仕様のデータ型や、標準のAPIだけで書けることが多い•副作用のない関数– 不変性（immutable)– setter を使わない• 閉じた操作– 自分自身の型を返す操作– (Javaだと) LocalDate, BigDecimal, String• こうすることで、プログラムの安定性が増す– 変更が楽で安全になる「しなやかな設計」
- 64.その他のテクニック• 表明– 「制約」による意図の明確化–ソフトウェアの安定性– 静的な型チェック、テスト、assert 文– @NotEmpty などの検証アノテーション• 宣言的スタイル– 体で覚える– SQL, HTML, CSS, XML , …– 関数型言語– Java/C#など、手続き型が基本の言語では、宣言的スタイルを、いつも意識すること
- 65.攻める角度• あらゆる場所を広く薄く攻めるのは費用対効果が悪い• サブドメインに切り分けて、重要な場所に集中する–わかりやすい単位にモジュールを切り出す– 残った部分もわかりやすくなる– 重要なサブドメインに集中してしやなかにするほうが効果的– 第１５章で、サブドメインの選択と管理について議論• 確立した概念体系を参考にする– 会計– 商取引(ビジネスプロトコル）– その分野で確立された計算式– そのまま深いモデルとしなやかな設計に使える基盤– そのビジネスに独自の価値を生み出す場所の発見は、また別の課題（ここも第１５章の議論）
- 66.第１０章のまとめ• しやなかな設計• 変更を楽で安全にするための工夫–多くの設計原則の動機• 「深いモデル」を探求するために概念を掘り出し表現することとコインの裏表• 技術者が「利用する人たちの関心事」に集中すための工夫• 「しやなか」なほど、実験がやりやすい• 実験の数をこなすほど「しなやか」さが向上する• 実験の場所を限定する
- 67.第11章 分析パターンを適用する• 「分析パターン」はゴールではなく出発点•「モデル」（重要な語彙）のネタ探し• 「ユビキタス言語」のネタ探し• 「公開された言語」も有用• その分野の（プログラミングとは関係ない）解説書や手引書も有用– 特に「目次」「図表」「用語集」– 「要約」されているから
- 68.
- 69.答えではなく「手掛り」• 良い点– 「利用する人たちの関心事」を「プログラムで表現」したパターン集–モデルと実装が結びついている• 気を付ける点– 過剰な抽象化、過剰な汎化– 一般的な状況をうまく説明できても、特殊な状況をするどく説明しているわけではない• 利用方法– 知らなかった概念や忘れていた概念の気づき– 何が問題で、どのようにそのパターンを導いたかの「考える過程」の参考– 「パターン」の具体例を、自分たちの「言葉」で書き換えてみる
- 70.第１２章デザインパターンをモデルに関係づける• デザインパターン– 技術的な側面に焦点をあてている–動機と解決策を技術的な観点と用語で説明• 「ドメイン」の概念を表現する道具として読み直す– 技術的なデザインパターンが、どのようにドメインの問題に適用できるか／できないか– 「ドメイン」の言葉で、そのパターンの動機と解決策を説明できるか？– チーム内の意識合わせのネタとして• 技術観点 vs. ドメイン観点
- 71.第１３章より深い洞察に向かうリファクタリング• 開始• 探求チーム•先達の技• 開発者のための設計• タイミング• 好機となる危機
- 72.リファクタリングのきっかけ• コードの複雑さやぎこちなさへの違和感• 言葉の不一致を感じた時•新しい要求がすんなりと既存のコードに適合しない時• コードを読んでいて、それを書いた時の理解が古い／まちがっていことを発見した時
- 73.リファクタリングの方向とタイミングを間違えないために• 選抜チームで取り組む– 変更を先導する人–問題を深く考えるのが得意な人– その領域の経験が深い人– 強力なモデリングスキルを持つ人• ユビキタス言語を駆使する– アイデアだし– 言葉による実験– コードによる実験• ドメインエキスパートの納得感をたいせつに– エキスパートが納得しない「深いモデル」はありえない– 「正解」を本人が説明できなくても「違和感」は直観できる
- 74.深いモデルへのリファクタリング実施の意思決定• 設計が、ドメインに関する「チーム」の現在の理解を表現していない時• 「重要な概念」が設計で暗黙的になっている時（かつ、それを明示的にする方法がわかっている時）•設計において「重要な部分」を、よりしなやかにする好機がある時
- 75.第３部 まとめ• 深いモデル–ドメインについての深い理解を表現したモデル– 利用者の「主要な関心事」の「明快な表現」– 表面的な側面を捨て去る– 利用する人たちの要望に機敏に対応する– 機敏に対応できないときは改善のチャンス• 何をすべきか– 「深いモデル」を目指した「リファクタリング」– 「言葉」を使って「チーム」で発見／実験／改良– 実験と成長のための「しなやかな設計」の工夫
- 76.ドメイン駆動リファクタリング• 「分割」ではなく「抽出」– メソッドの「抽出」–クラスの「抽出」– パッケージの「抽出」• 「抽出」– 利用者にとって意味のあるかたまりを見つける– 独立させる（メソッド、クラス、パッケージ）– 「役に立つ」名前をつける– この繰り返しが「しなやかな設計」への道ドメインの理解と実装の両方に役に立つ名前
- 77.概念を掘り出す努力を続けてますか？• 「言葉」に耳を傾ける• ぎこちなさを精査する•矛盾について熟考する• 文献を読む• 何度でも挑戦するドメイン駆動設計の実践のキモ９章を読みながら、個人やチームで振り返りを
- 78.
- 79.• どんな状況でも改善できる• どんなときでも「あなた」から改善を始められる•どんなときでも「今日」から改善を始められるエクストリームプログラミングの「はじめに」に記されたケント・ベックのメッセージ