Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ドメイン駆動設計 思えば遠くにきたもんだ

4,638 views

Published on

ドメイン駆動設計を始めてから、学んできたこと、今の立ち位置、進んでみたい方向

Published in: Software

ドメイン駆動設計 思えば遠くにきたもんだ

  1. 1. 「ドメイン駆動設計の実践」 思えば遠くにきたもんだ そして、道は続く ギルドワークス株式会社 増田 2015-09-19(土) DDD(ドメイン駆動設計)実践者の話を聞いてみよう
  2. 2. 歩きながら考え、考えながら歩く 楽しみながら 時には道に迷いながら 一歩一歩、「そこ」を目指して
  3. 3. 「そこ」を目指して歩き続ける ソフトウエアの核心にある複雑さ 変化に適応しながら成長を続ける ソフトウェアの変更容易性
  4. 4. ガイドブック Wabi Sabiを読み解く 生命の現象
  5. 5. 「まえがき」 凝集されたメッセージ • 「ドメイン駆動設計」のふるさと • 対照的な3つのプロジェクト • 複雑さという課題 • 設計対開発プロセス • 本書の構成 • 本書が対象とする読者 • ドメイン駆動チーム オブジェクト コミュニティ ドメインモデル ドメインという複雑さ XPと設計 目標/土台/主活動/広がり オブジェクト指向の開発者 最大の収穫を得る方法 「まえがき」を時々読みなおし、そのたびに新たな気づきを得る旅が続いている 自分がどこをめざしているか? どこまで到達できたか?
  6. 6. 「そこ」を目指して歩き続ける ソフトウエアの核心にある複雑さ 変化に適応しながら成長を続ける ソフトウェアの変更容易性
  7. 7. ソフトウェアの 核心にある複雑さ
  8. 8. 「まえがき」 複雑さという課題 • もっとも重要な複雑さは、技術的なものではない • 複雑なのは「ドメイン」そのもの • つまり「ユーザの活動やビジネス」そのものが複雑 • ソフトウェアにおけるこの複雑な側面を体系的に 扱うために – 一番の焦点はドメインとドメインロジックに合わせる – 複雑なドメインの設計は「モデル」にもとづかなければ ならない ここを理解しはじめた時が転換点 挑戦し、手ごたえと挫折を経験しながら、今も挑戦を続けている
  9. 9. 活動の目的/背景 ドメインとソフトウェア 利用する人たちの 活動と関心事 ソフトウェア
  10. 10. ドメインの「複雑さ」を扱うソフトウェア
  11. 11. ドメインの「複雑さ」を扱うソフトウェア • 重要な「複雑さ」は、ドメインそのもの • ドメインの「複雑さ」を「ドメイン層」に集める – プレゼンテーション層から「複雑さ」を取り除く – アプリケーション層から「複雑さ」を取り除く – データソース層から「複雑さ」を取り除く • 「ドメイン層」に集めた「複雑さ」は、 「モデル」を中核にして、見通しをよくし、秩序 だてていく
  12. 12. モデル • 膨大な知識を「要約」した シンプルでわかりやすい説明 • モデリングのスキル=「要約力」 –重要な要素を発見する力 –本質的でないものを削る力 –厳密に組み立てる力
  13. 13. ドメインモデル • ソフトウェアを利用する人たちの「活動」と 「関心事」の本質を簡潔に表したもの • 表現 –チームの会話に登場する「言葉」 –ラフスケッチ –コード –(文章や図)
  14. 14. コードで表現したドメインモデル
  15. 15. 第1部 ドメインモデルを機能させる 第2章 言葉を使った意図の伝達 第1章 ドメインの知識をかみ砕く 第3章 モデルと実装を結びつける ドメイン モデル ドメインの 膨大な情報を かみ砕き、蒸留して 重要な関心事を 鋭く説明する 選び抜かれた ドメインの重要な関心事を コードで表現する 会話を繰り返して 「要約」を改善する (重要点を明確にする) 「重要な語彙」をメンバーで 合意する/共有する
  16. 16. 「モデル」と「実装」を結びつける 「住所」を明示する 関連や集約の議論の広がり 関心事の「抽出」 クラスの「分割」ではない 関連/集約の設計は不要 O-R マッピングが簡単 暗黙の概念「住所」
  17. 17. • もっとも重要な複雑さは、技術的なものではない • 複雑なのは「ドメイン」そのもの • つまり、「ユーザの活動やビジネス」そのもの • ソフトウェアにおけるこの中心的な側面を体系的 に扱う – 一番の焦点はドメインとドメインロジックに合わせる – 複雑なドメインの設計は「モデル」にもとづかなければ ならない ソフトウエアの核心にある複雑さ ここを理解しはじめた時が転換点 挑戦し、手ごたえと挫折を経験しながら、今も挑戦を続けている
  18. 18. 変化に適応しながら 成長を続ける ソフトウェアの核心にある複雑さに立ち向かうために
  19. 19. 「適応型」のソフトウェア開発 開発の スタイル 方法論 ソフトウェアの 最終形(着地点) 開発サイクル 予測型 ウォータ フォール 事前に定義 厳密に定義 固定 分析/設計/製造 反復・ 漸進型 RUP それなりに定義 反復ごとに精緻化 方向付/推敲/作成/移行 各フェーズで分析/設計/製造を、 N回「反復」する 適応型 XP スクラム ざっくりと定義 日々更新 日、週、春夏秋冬 (人間の生活リズム) ここの発想の転換が大きな突破口 体にしみついたウォータフォールスタイルとの戦い
  20. 20. ソフトウェアの開発スタイル • 「変更」との戦い方の歴史 – 変更のコストとの戦い方 – 変更のリスクとの戦い方 • 「エクストリームプログラミング」は、積極的に 「変化を目指す」開発スタイル 変更を 管理する 変更を 受入れる 変化を 目指す 予測型 反復・漸進型 適応型 (創発型)
  21. 21. 転換点 • ずっと疑問だったこと – アジャイルでの「設計」のやり方 (やらない?) • 気づき – XPは設計に関するセンスを持った開発者にもっとも 適している by エリック・エヴァンス – 毎日、設計に投資する by ケント・ベック – オブジェクト指向では、分析/設計/実装/保守は「シー ムレス」である by バートランド・メイヤー • 行動 – オブジェクト指向の「変更容易性」の勉強のしなおし – 現場での体験と手ごたえ – エクストリームプログラミングの再発見
  22. 22. 変化を目指す開発チーム • コミュニケーション – 言葉を使って意図を伝える • シンプリシティ – 複雑になるほど変化が難しくなることを知っている • フィードバック – 経験/実験にもとづき進むべき道を探す • 勇気 – 行動する勇気、耐える勇気 • リスペクト – お互いの考えと行動に関心を持ち、かつ、尊重する
  23. 23. • ソフトウェア(の設計) – ドメインモデル – ドメイン層 – アプリケーション • ヒト – 開発チーム – 個人 変化に適応しながら成長を続ける ソフトウェアの核心にある複雑さに立ち向かうための開発スタイル ドメインモデルを少しずつ成長させていく ドメインモデルの成長は、チームの成長 (要求理解度や設計スキル) ドメインモデルとチームの成長がソフトウェア全体に波及しくいく
  24. 24. ソフトウェアの変更容易性 ソフトウェアの核心にある複雑さに立ち向かうために 変化に適応しながら成長を続けるために
  25. 25. オブジェクト指向と「変更容易性」 • 抽象データ型/段階的抽象化 – プログラムを人間の発想に近づけると扱いやすい • モジュラープログラミング – 独立性の高い部品に分けると扱いやすい • メッセージング – 部品の組合せ方を柔軟にすると扱いやすい どのパラダイムにも共通する設計の考え方 ドメイン層のコードは、たぶん似たものになる
  26. 26. LocalDate 日付を汎用的に扱う手段 Java APIのレイヤ int year short month short day LocalDateの内部 Java言語仕様のレイヤ if( day > 31 ) … DateOfBirth 「誕生日」に用途を限定した独自定義クラス 「ドメイン層」の一級市民(ドメインオブジェクト) 人間の発想 コンピュータの 仕組み 抽象データ型/段階的な抽象化 コードを人間の発想に近づける Boolean 今月が誕生月() Days 誕生日まであと何日() plusDays() plusMonths()
  27. 27. 「モジュール化」と「メッセージング」 受付役 仲介役 回答役 経路情報 専門家 判定役 おーい 手伝って 後は まかせた おーい 考えて おーい 教えて 教えて 最短経路は… 独立性の高い部品 独立性の高い部品 独立性の高い部品 独立性の高い部品 独立性の高い部品 人間の営みと同じ仕組み 必要に応じて最適チームを結成
  28. 28. オブジェクト指向への道 • よくわかっていなかった – 本を読んでもわからない – コード書いてもぴんとこない – 冗長で遅いだけ? • 1990 頃 Unix/C • 1995 頃 DOA+手続き型プログラミング – Oracle, PL/SQL, Pro*C • 1998 頃 – Java, DTO, 長いメソッド,大きなクラス • 2005年12月30日 運命の電話
  29. 29. 転換点 • 変更に苦しんだ大炎上プロジェクト (C#) – どこに何が書いてあるかわからない – 変更した時に、どこで何がおきるかわからない – 同じ修正をあちこちに適用 • 修正漏れ • 不要な箇所のまちがった修正 • リファクタリング – 面白いように効果がでてくる – メソッドの抽出 – クラスの抽出 – プレゼンテーションとドメインの分離 – 手続き型からオブジェクト指向へ
  30. 30. 手続き型からオブジェクト指向へ • 値オブジェクト – データとロジックを一箇所にまとめる – 状態を変えない/自分と同じ型のオブジェクトを返す – 「型名」を使った意図の伝達 • インスタンス変数の「型名」 • 引数の「型名」 • メソッドの返す「型名」 • ファーストクラスコレクション – インスタンス変数にコレクションを持つオブジェクト – コレクションの操作の置き場所 – 可変性の閉じ込め方 • メソッドオブジェクトによるメソッドの置き換え – 長いメソッド/複雑なローカル変数の使い方 • 「データクラス」へ「ロジック」を移動 変更が楽に安全になる手ごたえ
  31. 31. その次にきた転換点 • 基本構造は「トランザクションスクリプト」だった – アクション駆動(ユースケース駆動) – DTOとコードの重複 – プレゼンテーション層へのドメインロジックの分散 • ドメインモデルパターンへ – ドメインオブジェクト • 分析クラスをそのまま実装クラスに – ドメイン層 • ドメインオブジェクトのネットワーク – 機能駆動/画面駆動/テーブル駆動ではない設計ス タイルへ
  32. 32. ドメインモデルパターンへ • 「重複が減る」 – by マーチン・ファウラー – 飛びついた – やってみたら、ほんとうに重複が減った • 「ドメイン層」の開発に集中せよ – Spring それ以外の層は俺たちが良いものを提供 するぜ by ロッド・ジョンソン – ソフトウェアの複雑さの核心は「ドメイン」そのもの by エリック・エヴァンス
  33. 33. ドメインの「複雑さ」を扱うソフトウェア
  34. 34. 他の層からドメインオブジェクトを使う • プレゼンテーション層 – Thymeleaf • ピュアな HTML とドメインオブジェクトのマッピング技術 • アプリケーション層 – @Service • 「やりたいこと」の宣言のみ • 具体的な判断・加工・計算はドメインオブジェクトまかせ • データソース層 – MyBatis • ピュアな SQL とドメインオブジェクトのマッピング技術
  35. 35. • ドメインオブジェクト • 独立性の高い部品 • 柔軟な組み合わせ ソフトウェアの変更容易性 実戦的な練習 考え方の勉強 Spring Boot Thymeleaf MyBatis Java 8 実装技術 しなやかな設計 ドメインモデルの進化を加速
  36. 36. まとめ
  37. 37. 「そこ」を目指して歩き続ける ソフトウエアの核心にある複雑さ 変化に適応しながら成長を続ける ソフトウェアの変更容易性
  38. 38. 一歩一歩、「そこ」を目指して 歩きながら考え、考えながら歩く 楽しみながら 時には道に迷いながら

×