Download as PDF, PPTX
More Related Content
ドメイン駆動設計 思えば遠くにきたもんだ
- 1.
- 2.
- 3.
- 4.
- 5. 「まえがき」 凝集されたメッセージ • 「ドメイン駆動設計」のふるさと •対照的な３つのプロジェクト • 複雑さという課題 • 設計対開発プロセス • 本書の構成 • 本書が対象とする読者 • ドメイン駆動チーム オブジェクト コミュニティ ドメインモデル ドメインという複雑さ ＸＰと設計 目標/土台/主活動/広がり オブジェクト指向の開発者 最大の収穫を得る方法 「まえがき」を時々読みなおし、そのたびに新たな気づきを得る旅が続いている 自分がどこをめざしているか？ どこまで到達できたか？
- 6.
- 7.
- 8. 「まえがき」 複雑さという課題 • もっとも重要な複雑さは、技術的なものではない •複雑なのは「ドメイン」そのもの • つまり「ユーザの活動やビジネス」そのものが複雑 • ソフトウェアにおけるこの複雑な側面を体系的に 扱うために – 一番の焦点はドメインとドメインロジックに合わせる – 複雑なドメインの設計は「モデル」にもとづかなければ ならない ここを理解しはじめた時が転換点 挑戦し、手ごたえと挫折を経験しながら、今も挑戦を続けている
- 9.
- 10.
- 11. ドメインの「複雑さ」を扱うソフトウェア • 重要な「複雑さ」は、ドメインそのもの • ドメインの「複雑さ」を「ドメイン層」に集める –プレゼンテーション層から「複雑さ」を取り除く – アプリケーション層から「複雑さ」を取り除く – データソース層から「複雑さ」を取り除く • 「ドメイン層」に集めた「複雑さ」は、 「モデル」を中核にして、見通しをよくし、秩序 だてていく
- 12.
- 13.
- 14.
- 15.
- 16.
- 17. • もっとも重要な複雑さは、技術的なものではない • 複雑なのは「ドメイン」そのもの •つまり、「ユーザの活動やビジネス」そのもの • ソフトウェアにおけるこの中心的な側面を体系的 に扱う – 一番の焦点はドメインとドメインロジックに合わせる – 複雑なドメインの設計は「モデル」にもとづかなければ ならない ソフトウエアの核心にある複雑さ ここを理解しはじめた時が転換点 挑戦し、手ごたえと挫折を経験しながら、今も挑戦を続けている
- 18.
- 19.
- 20. ソフトウェアの開発スタイル • 「変更」との戦い方の歴史 – 変更のコストとの戦い方 –変更のリスクとの戦い方 • 「エクストリームプログラミング」は、積極的に 「変化を目指す」開発スタイル 変更を 管理する 変更を 受入れる 変化を 目指す 予測型 反復・漸進型 適応型 （創発型）
- 21. 転換点 • ずっと疑問だったこと – アジャイルでの「設計」のやり方（やらない？） • 気づき – ＸＰは設計に関するセンスを持った開発者にもっとも 適している by エリック・エヴァンス – 毎日、設計に投資する by ケント・ベック – オブジェクト指向では、分析/設計/実装/保守は「シー ムレス」である by バートランド・メイヤー • 行動 – オブジェクト指向の「変更容易性」の勉強のしなおし – 現場での体験と手ごたえ – エクストリームプログラミングの再発見
- 22. 変化を目指す開発チーム • コミュニケーション – 言葉を使って意図を伝える •シンプリシティ – 複雑になるほど変化が難しくなることを知っている • フィードバック – 経験／実験にもとづき進むべき道を探す • 勇気 – 行動する勇気、耐える勇気 • リスペクト – お互いの考えと行動に関心を持ち、かつ、尊重する
- 23. • ソフトウェア（の設計） – ドメインモデル –ドメイン層 – アプリケーション • ヒト – 開発チーム – 個人 変化に適応しながら成長を続ける ソフトウェアの核心にある複雑さに立ち向かうための開発スタイル ドメインモデルを少しずつ成長させていく ドメインモデルの成長は、チームの成長 （要求理解度や設計スキル） ドメインモデルとチームの成長がソフトウェア全体に波及しくいく
- 24.
- 25. オブジェクト指向と「変更容易性」 • 抽象データ型／段階的抽象化 – プログラムを人間の発想に近づけると扱いやすい •モジュラープログラミング – 独立性の高い部品に分けると扱いやすい • メッセージング – 部品の組合せ方を柔軟にすると扱いやすい どのパラダイムにも共通する設計の考え方 ドメイン層のコードは、たぶん似たものになる
- 26. LocalDate 日付を汎用的に扱う手段 Java APIのレイヤ int year shortmonth short day LocalDateの内部 Java言語仕様のレイヤ if( day > 31 ) … DateOfBirth 「誕生日」に用途を限定した独自定義クラス 「ドメイン層」の一級市民（ドメインオブジェクト） 人間の発想 コンピュータの 仕組み 抽象データ型／段階的な抽象化 コードを人間の発想に近づける Boolean 今月が誕生月() Days 誕生日まであと何日() plusDays() plusMonths()
- 27.
- 28. オブジェクト指向への道 • よくわかっていなかった – 本を読んでもわからない –コード書いてもぴんとこない – 冗長で遅いだけ？ • 1990 頃 Unix/C • 1995 頃 DOA＋手続き型プログラミング – Oracle, PL/SQL, Pro*C • 1998 頃 – Java, DTO, 長いメソッド,大きなクラス • 2005年12月30日 運命の電話
- 29. 転換点 • 変更に苦しんだ大炎上プロジェクト (C#) –どこに何が書いてあるかわからない – 変更した時に、どこで何がおきるかわからない – 同じ修正をあちこちに適用 • 修正漏れ • 不要な箇所のまちがった修正 • リファクタリング – 面白いように効果がでてくる – メソッドの抽出 – クラスの抽出 – プレゼンテーションとドメインの分離 – 手続き型からオブジェクト指向へ
- 30. 手続き型からオブジェクト指向へ • 値オブジェクト – データとロジックを一箇所にまとめる –状態を変えない／自分と同じ型のオブジェクトを返す – 「型名」を使った意図の伝達 • インスタンス変数の「型名」 • 引数の「型名」 • メソッドの返す「型名」 • ファーストクラスコレクション – インスタンス変数にコレクションを持つオブジェクト – コレクションの操作の置き場所 – 可変性の閉じ込め方 • メソッドオブジェクトによるメソッドの置き換え – 長いメソッド／複雑なローカル変数の使い方 • 「データクラス」へ「ロジック」を移動 変更が楽に安全になる手ごたえ
- 31. その次にきた転換点 • 基本構造は「トランザクションスクリプト」だった – アクション駆動（ユースケース駆動） –DTOとコードの重複 – プレゼンテーション層へのドメインロジックの分散 • ドメインモデルパターンへ – ドメインオブジェクト • 分析クラスをそのまま実装クラスに – ドメイン層 • ドメインオブジェクトのネットワーク – 機能駆動／画面駆動／テーブル駆動ではない設計ス タイルへ
- 32. ドメインモデルパターンへ • 「重複が減る」 – byマーチン・ファウラー – 飛びついた – やってみたら、ほんとうに重複が減った • 「ドメイン層」の開発に集中せよ – Spring それ以外の層は俺たちが良いものを提供 するぜ by ロッド・ジョンソン – ソフトウェアの複雑さの核心は「ドメイン」そのもの by エリック・エヴァンス
- 33.
- 34. 他の層からドメインオブジェクトを使う • プレゼンテーション層 – Thymeleaf •ピュアな HTML とドメインオブジェクトのマッピング技術 • アプリケーション層 – @Service • 「やりたいこと」の宣言のみ • 具体的な判断・加工・計算はドメインオブジェクトまかせ • データソース層 – MyBatis • ピュアな SQL とドメインオブジェクトのマッピング技術
- 35. • ドメインオブジェクト • 独立性の高い部品 •柔軟な組み合わせ ソフトウェアの変更容易性 実戦的な練習 考え方の勉強 Spring Boot Thymeleaf MyBatis Java 8 実装技術 しなやかな設計 ドメインモデルの進化を加速
- 36.
- 37.
- 38.