ソフトウェアの実装と事業戦略を結びつける

『ドメイン駆動設計をはじめよう』の概要説明

①この本で学んでほしいこと（原著者の思い）
②原著者のドメイン駆動設計のとらえ方
③この本の特徴
④ソフトウェア実装と事業戦略を結びつける方法
⑤事業の成長とソフトウェアの成長
⑥開発チームの学習と成長

Transcript

1. ソフトウェアの実装と 事業戦略を結びつける実践技法 2024年8月20日 有限会社システム設計 増田 亨 1 『ドメイン駆動設計をはじめよう』
2. 自己紹介 業務系アプリケーションソフトウェアの開発者 モデル駆動設計 Java/Spring Boot/IntelliJ IDEA/JIG 有限会社システム設計 代表 since 2003 コミューン株式会社 技術アドバイザ since 2023 2 増田 亨（ますだ とおる） 著書(2017) 訳書(2024)
3. 『ドメイン駆動設計をはじめよう』 Amazon.comで高評価(★4.6, 302review) “Learning Domain-Driven Design” の全訳 「ドメイン駆動設計を実践するために 最初に手にするべき1冊！」 by 出版社 ドメイン駆動設計抜きにしても、よいことが書いてある by もう一人の訳者綿引さん 3 ソフトウェアの実装と事業戦略を結びつける実践技法
4. 今日の内容 ① この本で学んでほしいこと（原著者の思い） ② 原著者のドメイン駆動設計のとらえ方 ③ この本の特徴 ④ ソフトウェア実装と事業戦略を結びつける方法 ⑤ 事業の成長とソフトウェアの成長 ⑥ 開発チームの学習と成長 ⑦ Ｑ＆Ａ 4
5. この本で学んでほしいこと 5
6. 「はじめに」xxixより “この本で学んでほしいことは、 ソフトウェア設計と事業方針を 密接に関係づけることの効果です。” 6
7. 設計 判断 事業活動とソフトウェア設計を結びつける 7 事業活動 課題 課題 仕組み 仕組み 関係者 開発者が理解 トランザクション スクリプト アクティブ レコード ドメイン モデル イベント履歴式 ドメインモデル 値オブジェクト 集約 業務サービス レイヤード ポートと アダプター CQRS Web API メッセージング 送信箱 サーガ プロセス マネージャー イベント駆動型 アーキテクチャ マイクロ サービス データメッシュ トランザクション ロールバック 排他制御 テスト戦略 イベント ストーミング 大きな リファクタリング （第１章～第４章） 設計の選択肢（第５章～第１６章） （第10章、付録A） この本の全体像 実践知
8. ソフトウェア設計と事業方針 この本の考え方 1. ソフトウェアを開発する目的は事業を成長させること 2. 事業を成長させるためには、ソフトウェアの修正と拡張が必要 3. 設計と事業方針が結びつけば、変更が楽で安全になる 8 こういう視点で、ソフトウェア設計の考え方とやり方を説明している本 技術的な実装方法だけを学びたいなら、適切な本ではない
9. 原著者(Vlad Khononovさん)の ドメイン駆動設計のとらえ方 9 エヴァンス『ドメイン駆動設計』：原典。ただし、用語の定義や関係性があいまい。 ヴァーノン『実践ドメイン駆動設計』：エヴァンス本の発想と用語間の関係性を（独自に）再定義 『ドメイン駆動設計をはじめよう』：両者を参考にした実践経験をもとに、ヴァーノン本をさらに具体化
10. ドメイン駆動設計のテーマは二つある •設計の基本方針の検討（第Ⅰ部） •実装方法の選択（第Ⅱ部） 10
11. 第Ⅰ部：設計の基本方針の検討 • ドメイン駆動設計は設計の基本方針を検討するための技法を提供 • 事業活動と事業戦略を分析し 利害関係者の間で事業についての認識を合わせる（第１章） • 事業の理解にもとづいてソフトウェア設計の基本方針を決める （第２章、第３章） • システム全体をいくつかのコンポーネント（区切られた文脈）に分割し、 コンポーネントどうしのつなぎ方を事業の視点から判断(第３章、第４章) 11
12. 第Ⅱ部：実装方法の選択 • 業務ロジックが単純な場合の実装方法（第５章） • 業務ロジックが複雑な場合のドメイン駆動設計らしい実装方法（第６章） • 業務ロジックを実装するより進んだ実装方法（第７章） • アプリケーション全体の組み立て方（第８章） • アプリケーションどうしをつなぐ通信方法（第９章） 12 事業課題と事業戦略の分析結果から、どの実装方法をどこに使うかを判断する
13. この本の特徴 13
14. この本の価値 現代的なドメイン駆動設計本 • 『ドメイン駆動設計』(原著2003年）、『実践ドメイン駆動設計』(原著 2013年）が出版されて以降のさまざまな実践知を体系的に整理 • イベントソーシング、CQRS、イベントストーミング、マイクロサービス、 データメッシュなど、最近の分散型アーキテクチャとの関係を具体的に説明 わかりやすく現場で取り組みやすいドメイン駆動設計本 • なぜそうするか（Why）の説明が一貫している • 事業活動と業務知識の具体例が豊富 • 多様な設計課題を相互に関係づけて解説している • 要点を図、コード、表でわかりやすく説明している 14
15. 誰が読むべき本か？ すべてのソフトウェア開発者の役に立つはず しかし • 開発者としての知識や経験の違いによって、理解できる範囲が異なる • 現在の置かれている状況や当面の課題によって、役に立つ個所が異なる だからこそ • 現在の自分の知識、関心、必要性をこの本と対比してみる • チームで、お互いの理解の違い、関心の違いをこの本を題材に話し合ってみる • もっと経験を積んでから読み直してみる 15
16. この本の意図をわかりやすく伝えるために 原語 従来の訳語 本書の訳語 domain ドメイン 事業活動 subdomain サブドメイン 業務領域 domain logic ドメインロジック 業務ロジック core domain コアドメイン 中核の業務領域 ubiquitous language ユビキタス言語 同じ言葉 bounded context 境界づけられたコンテキスト 区切られた文脈 context map コンテキストマップ 文脈の地図 16
17. 17 技術者がドメインとサブドメインを理解し 境界づけられたコンテキストでユビキタス言語を使って ソフトウェアを開発する 技術者が事業活動と業務領域を理解し 区切られた文脈で同じ言葉を使って ソフトウェアを開発する
18. ソフトウェアの実装と 事業戦略を結びつける方法 18
19. 基本的なやり方 19 事業活動全体を複数の業務領域に分解 それぞれの業務領域を事業戦略の視点から 三つのカテゴリーに分類 業務領域のカテゴリーが決まれば 業務ロジックの実装方法が決まる 業務ロジックの実装方法が決まれば アプリケーションの技術方式が決まる 業務ロジックの実装方法が決まれば テスト方針が決まる 第１ステップ 第２ステップ 第３ステップ 第４ステップ 第５ステップ ここがキモ！
20. 事業活動を業務領域に分解する 事業活動（ドメイン） • 顧客にどんな価値を提供しているか • どうやってその価値を提供しているか • 競合他社とどうやって差別化し競争優位を生み出し維持するか 業務領域（サブドメイン） • 事業活動の領域全体を細分化したもの • すべての業務領域が一体となって顧客に価値を提供する • 販売促進、販売、顧客サービス、出荷、在庫、会計、財務、人事、… 20
21. 事業戦略の視点から業務領域を分類 中核の業務領域 • 競争優位の源泉 • 業務ロジックが複雑 • 変化を繰り返す 一般的な業務領域 • 他社と同じやり方でよい • 業務ロジックは複雑 • あまり変化しない 補完的な業務領域 • 自社独自のやり方が必要 • 業務ロジックは単純 • あまり変化しない 21 業務領域の細分化と 三つのカテゴリーへの分類が 設計判断の基本枠組みとなる
22. 対象の業務領域のカテゴリーを特定する 22 業務ロジックの複雑さと 競合他社との差別化の二軸で分類 中核に重点的に取り組む（事業価値が最も高い） 一般はパッケージやクラウドサービスを検討 補完はできるだけ手間をかけずにすませる
23. 業務ロジックの実装方法の選択 23 （第５章） （第６章） （第７章） （第１章）
24. 業務領域のカテゴリーから 業務ロジックの実装方法が決まると 24 アプリケーションの技術方式が決まる テストの基本方針が決まる （第８章） （第１０章）
25. 業務領域の分類の具体例（第１章） 25 中核（競争優位） • 推薦エンジン • データの匿名化 • モバイルアプリ 一般 • 暗号化 • 会計 • 決済 • 認証と認可 補完 • 音楽ストリーミングサービスとの連係 • SNSとの連携 • ライブ参加履歴の管理 中核（競争優位） • 運行経路の選択 • 利用者の行動分析 • モバイルアプリ • 車両の管理 一般 • 交通状況 • 会計 • 請求 • 認証と認可 補完 • クーポン発行 • クーポンの有効性チェック ライブチケットのオンライン販売事業 相乗りタクシー型ミニバスサービス こういう事業分析や業務知識の具体例が多いのがこの本の価値
26. 事業の成長と ソフトウェアの成長 26 （第11章 設計を進化させる）
27. 業務領域のカテゴリーは変化する 27 事業が成長すれば、業務領域の カテゴリーは変化する 業務領域のカテゴリーの変化に応じて 設計方針を変える
28. 業務領域のカテゴリーに合わせた設計 28 （第１章） （第５章） （第６章） （第７章）
29. 開発チームの学習と成長 （付録A） 29 原著者の経験談（失敗談） そこからの学び
30. 現実世界のドメイン駆動設計 こういうことはありえないし、必要もない（第13章） • チーム全員がドメイン駆動設計を熟知している • 最初から全員が役に立つモデルの探求に全力をつくす • 全ての関係者が同じ言葉を忠実に使う • 既存システムや外部サービスを考慮しなくてよい制約の少ない新規案件 ドメイン駆動設計のすべての技法を使う必要はない ドメイン駆動設計が組織として受け入れられていない状況でも実践は可能  適切な道具を必要に応じて選択的に使う  それぞれのやり方の背景にある考え方と原則を意識して使う  組織の変化とソフトウェアの成長に忍耐強く取り組む 30
31. ドメイン駆動設計：最初の理解 31 とにかく集約！ ドメイン駆動設計の表面的、かつ、 断片的な理解で取り組んだ段階 （失敗） (成功)
32. 第一の学び：「同じ言葉」の効果 32 業務知識が欠落するソフトウェア開発 業務知識が豊富なソフトウェア開発 同じ言葉 （業務の言葉） （第２章）
33. ドメイン駆動設計：失敗から学ぶ 33 同じ言葉の通用範囲の確立 同じ言葉の完全性の保護 貧血ドメインモデルから 知識豊かなドメインモデルへ モデルの複雑化→納期遅れ→誤った分業体制 完全に理解した！ (成功) (成功) （失敗）
34. 第二の学び：「区切られた文脈」の効果 34 • 同じ言葉の通用する範囲 • モデルの境界 • 開発単位の境界 • チームの責任範囲の境界 複雑さを扱うために 文脈を区切る （第３章）
35. ドメイン駆動設計：本格的な理解 35 事業戦略と整合した設計判断ができるようになった！ （第１章） （第２章） （第３章） （第６章、第7章） （第５章）
36. 第三の学び：業務領域のカテゴリー 36 業務領域を２軸で分類 カテゴリーから実装方法を選択 （第１章）
37. 今日のまとめ 37
38. 「はじめに」xxixより “この本で学んでほしいことは、 ソフトウェア設計と事業方針を 密接に関係づけることの効果です。” 38
39. 設計 判断 事業活動とソフトウェア設計を結びつける 39 事業活動 課題 課題 仕組み 仕組み 関係者 開発者が理解 トランザクション スクリプト アクティブ レコード ドメイン モデル イベント履歴式 ドメインモデル 値オブジェクト 集約 業務サービス レイヤード ポートと アダプター CQRS Web API メッセージング 送信箱 サーガ プロセス マネージャー イベント駆動型 アーキテクチャ マイクロ サービス データメッシュ トランザクション ロールバック 排他制御 テスト戦略 イベント ストーミング 大きな リファクタリング （第１章～第４章） 設計の選択肢（第５章～第１６章） （第10章、付録A） この本の全体構成 実践知
40. 分散型アーキテクチャと ドメイン駆動設計 40 ＜時間があれば＞ こういう内容も書かれています（４章、９章、14章、15章、16章）
41. 第４章 区切られた文脈どうしの連係 41 対等の関係 力関係が片寄った関係
42. 文脈の地図（連係の全体像） 42 この地図からわかること ・顧客管理が中核の業務領域 ・それ以外は一般または補完 中核モデルの独自性を 保護するための設計判断
43. 第９章 通信 43 （区切られた文脈どうしの連係を実装する技術方式）
44. ドメイン駆動設計と分散型アーキテクチャ 44 マイクロサービスアーキテクチャ （第14章） イベント駆動型アーキテクチャ （第15章） データメッシュ （第1６章） 区切られた文脈の考え方で取り組む