Tweet
Tweet

Slide 1

Slide 1 text

『Learning Domain-Driven Design』
 📚 輪読会 #1🐒
 株式会社Showcase Gig 
 鈴木 慎一郎（@suzushin54） 
 #lddd_rindoku 2022/03/24


Slide 2

Slide 2 text

Disclaimer
 ❏ 本スライドは、以下の書籍を要約・引用の範囲内で紹介します。 
 ❏ Vladik Khononov『Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy』Oreilly & Associates Inc (2021/11/2) 
 ❏ https://www.oreilly.com/library/view/learning-domain-driven-design/9781098100124/ 
 ❏ 原文、正確な翻訳文は著作権法および翻訳権に抵触するため掲載しません。 
 
 2

Slide 3

Slide 3 text

Overview
 ❏ Foreword （著者以外が書いた前書き） 
 Julie Lerman - Software Coach, O’Reilly Author, and Serial DDD Advocate 
 ❏ Preface（著者の前書き）
 Vlad (Vladik) Khononov - Software Engineer (20+ yrs), public speaker, blogger, and author. 
 ❏ この本を書いた理由 
 ❏ 対象読者
 ❏ この本のナビゲーション 
 ❏ ドメインの例
 ❏ Introduction（導入部）
 3

Slide 4

Slide 4 text

Foreword - 前書き (1/4)
 ❏ ドメイン駆動設計（以下、DDD ） は、ビジネスの観点からソフトウェアを構築するための協調的 なアプローチ
 ❏ ドメインと、その問題を対象とするプラクティスを提供するもの 
 ❏ 2003年に Eric Evans が発表した書籍からはじまったコンセプト 
 ❏ DDD Community では “The Blue Book” として親しまれている 
 『Domain-Driven Design: 
 Tackling Complexity in the Heart of Software』 『エリック・エヴァンスのドメイン駆動設計 
 ソフトウェアの核心にある複雑さに立ち向かう』 4

Slide 5

Slide 5 text

Foreword - 前書き (2/4)
 ❏ DDD の目的は、複雑さに取り組み、明確な道筋を示すこと 
 ❏ 開発者だけがソフトウェア開発に関わっているわけではないことを思い出させてくれる 
 ❏ ドメインエキスパートは、ドメインに対して重要な理解をもたらす存在である 
 
 ❏ 戦略的設計 (strategic design) 
 ❏ ビジネスの問題 (domain) を理解すること 
 ❏ 小さく、解決可能で、互いに関連した問題に分解する 
 ❏ ビジネス側の人間とはドメインの言語でコミュニケーションする 
 ❏ 戦術的設計 (tactical design)
 ❏ 戦略的設計で発見したことをアーキテクチャと実装に落とし込む 
 ❏ ここでもドメインの言語でコミュニケーションする 
 5

Slide 6

Slide 6 text

Foreword - 前書き (3/4)
 ❏ Eric Evans さんは 2019年の Explore DDD の基調講演に登壇 
 ❏ DDD を進化させ続けること
 ❏ 実践だけでなくアイディアを共有する方法を見つけること、を呼びかけた 
 Explore DDD Conference 
 http://exploreddd.com/
 6

Slide 7

Slide 7 text

Foreword - 前書き (4/4)
 ❏ 本書は新参者向けではあるが、経験豊富な実践者にとっても読み応えがあるもの 
 ❏ DDD を始める時には混乱することがあるが、本書はシンプルにトピックを紹介している 
 ❏ 本書の後半では、EventStorming など DDD から発展したプラクティスも紹介 
 ❏ マイクロサービスや、よく知られた設計パターンと統合できるかについても論じている 
 
 7

Slide 8

Slide 8 text

Preface
 ❏ 初めて Software Engineering の仕事に就いた日のことを鮮明に覚えている 
 ❏ “Real Programmer” になってコードを書きたいと思っていた 
 ❏ そこで同僚が手取り足取り教えてくれた 
 “でも、ビジネスロジック層はどうするんですか？” 
 “あれは簡単だよ。ここにビジネスロジックを実装するんだ” 
 “でもビジネスロジックって何ですか？” 
 “要件を実現するために必要なループや if-else 文のことだよ” 
 ❏ その日から、ビジネスロジックとは何かを知る旅に出た 
 ❏ 答えは、『Domain-Driven Design』にあった 
 ❏ やはりビジネスロジックは重要で、ソフトウェアの心臓部だった 
 8

Slide 9

Slide 9 text

Preface - この本を書いた理由
 ❏ 様々な会社で同僚に DDD を紹介したり、レクチャーしたりしてきた 
 ❏ 自身の理解を深めるだけでなく、原理やパターンの説明の最適化に役立った 
 ❏ 私はエリヤフの仕事と教えの大ファン。彼はよく次のように言っていた 
 “どんなに複雑なシステムでも、正しいアングルから見れば本質的にはシンプルである”
 ❏ DDD を教える過程で、DDD の本質的なシンプルさを明らかにしようとしてきた 
 ❏ 本書はその成果である
 ❏ この本の目的は、DDD を民主化すること
 ❏ つまり、理解しやすく採用しやすいものにすること 
 https://ja.wikipedia.org/wiki/エリヤフ・ゴールドラット 
 世界的ベストセラー『ザ・ゴール』で知られるイスラエルの経営学の第一人者 
 9

Slide 10

Slide 10 text

Preface - この本を読むべき人
 ❏ あらゆるレベルの Software Engineer にとって有用である 
 ❏ Software Architect にとっては、さらに重要なもの 
 ❏ 大規模なシステムをサブシステムやマイクロサービスなどのコンポーネントに 
 分解、統合してシステムを形成する設計をするために役立つ 
 ❏ ただ設計するだけでなく、ビジネスの変化に合わせて進化させる方法も解説している 
 ❏ 設計を正常な状態に保ち、時間の経過とともに 大きな泥団子 になるのを防ぐ
 
 10

Slide 11

Slide 11 text

Preface - この本のナビゲーション
 ❏ 4つのパートで構成されている
 1. 戦略的設計
 大規模なソフトウェア設計のためのツールやテクニックを紹介 
 2. 戦術的設計
 コードにフォーカスし、ビジネスロジックを実装する方法を紹介 
 3. DDD の実践
 実際のプロジェクトで DDD を導入するためのテクニックと戦略を解説 
 4. 他の方法論やパターンとの関係
 DDD と、方法論やパターンとの関係を議論する 
 11

Slide 12

Slide 12 text

Preface
 ● 1章: プロジェクトのコンテキスト（すなわちドメイン、そのゴール）、それをサポートするためのソフトウェアのあり方について
 ● 2章: 効果的なコミュニケーションと知識共有のための「ユビキタス言語」の概念を紹介
 ● 3章: ドメインの複雑性に取り組み、境界づけられたコンテキストを設計する方法
 ● 4章: 境界づけられたコンテキスト間のコミュニケーションと、統合を組織化するためのパターンについて
 ● 5章: ビジネスロジックの実装パターンについて、単純なロジックに対応する2つのパターンから議論する 
 ● 6章: 単純なビジネスロジックから複雑なビジネスロジックへと進み、複雑さに対処するためのドメインモデルパターンを紹介
 ● 7章: 時間という視点を加えた、より高度なビジネスロジックのモデル化。その実装方法としてイベントソースドメインモデルを紹介
 ● 8章: コンポーネントを構造化するための 3つのアーキテクチャパターンを説明
 ● 9章: コンポーネントの作業をオーケストレーションするために必要なパターンを紹介
 ● 10章: これまでに紹介したパターンをいくつかの経験則にまとめ、設計の意思決定プロセスを効率化する
 ● 11章: ソフトウェアがその生涯でどのように変化・進化することになるか、時間の観点から設計を探求する 
 ● 12章: EventStorming を紹介。知識を効果的に共有し、共通理解を作る、設計のローテクワークショップ 
 ● 13章: “brownfield” プロジェクトに DDD を導入する時に直面するかもしれない問題について
 ● 14章: マイクロサービスアーキテクチャと DDD の関係について、それぞれの違いと補完関係を議論する
 ● 15章: イベント駆動アーキテクチャの文脈における DDD のパターンとツールについて検討
 ● 16章: 運用システムから分析データ管理システムに論点を移し、DDD とデータメッシュアーキテクチャの相互作用を議論
 12

Slide 13

Slide 13 text

Preface - ドメイン例 (WolfDesk)
 ❏ ヘルプデスクチケット管理システムをサービスとして提供している 
 ❏ 競合他社とは異なる支払いモデルを採用している 
 ❏ ユーザ数の課金ではなく、サポートチケット数で課金される 
 ❏ 最低利用料金はなく、ボリュームディスカウントが自動適用される 
 ❏ 月500件以上で10%、750件以上で20% …etc 
 ❏ 悪用防止のためのチケットライフサイクル アルゴリズムがある 
 ❏ “サポート・オートパイロット”機能があり、履歴から解決策を提示したりする 
 ❏ 認証認可のためのセキュリティ標準。既存のユーザ管理システムとSSOを設定可能 
 ❏ サポートエージェントのシフト入力が可能 
 13

Slide 14

Slide 14 text

Introduction(1/2)
 ❏ Software Engineering は難しい
 ❏ 新しい言語、技術、成功のためには学び続けないといけない 
 ❏ しかし毎週新しい JavaScript の Framework を学ぶことよりも、 
 新しいビジネスドメインを学ぶことの方がずっとチャレンジングである 
 ❏ ビジネスドメインを把握できていないと、実装は最適なものではなくなる 
 ❏ 調査によると、ソフトウェア開発プロジェクトの70%はQCDを満たさない(＝失敗) 
 ❏ ソフトウェア危機(Software Crisis)という言葉まで生まれた 
 ❏ それに対して、数多くのアプローチや方法論が導入されてきた 
 ❏ Agile, XP, TDD, 高級言語, DevOps …etc 
 ❏ しかし、状況はあまり変わっていない 
 14

Slide 15

Slide 15 text

Introduction(2/2)
 ❏ なぜプロジェクトはうまくいかないのか？ 
 ❏ 研究によると、“コミュニケーション”という共通のテーマがありそう 
 ❏ 不明瞭な要求、プロジェクトゴール、チーム間の調整 …etc 
 ❏ そのため、新たなコミュニケーション機会やプロセスの導入などで改善を 
 試みてきたが、プロジェクトの成功率はあまり変わらなかった 
 ❏ DDD は、プロジェクトの失敗原因に対して、異なるアングルから取り組むもの 
 ❏ それが、戦略的ツールと、戦術的ツール 
 ❏ 設計とビジネス戦略の結びつきが強いほど、将来のビジネス要求に合わせてシステムをメンテ ・進化させやすくなる
 ❏ Let’s start our DDD journey !
 15