Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Learning DDD輪読会#1
Search
suzushin54
March 24, 2022
Programming
2
940
Learning DDD輪読会#1
株式会社Showcase Gig主催の輪読会の資料です。
https://showcase-gig.connpass.com/event/241338/
suzushin54
March 24, 2022
Tweet
Share
More Decks by suzushin54
See All by suzushin54
ドメイン・ファーストで考える問題解決に役立つモデル設計 / Domain First Model Design
suzushin54
2
2.2k
Learning DDD輪読会#15 / Learning DDD Book Club #15
suzushin54
1
190
認知的複雑度から見るGo言語のイベントソーシング実装 / Event Sourcing with Go
suzushin54
7
4.4k
Learning DDD輪読会#9 / Learning DDD Book Club #9
suzushin54
0
240
Learning DDD輪読会#4 / Learning DDD Book Club #4
suzushin54
1
600
複数の境界づけられたコンテキストにおける共通ロジックの扱いについて / Handling common logic in multiple contexts
suzushin54
1
1.5k
Other Decks in Programming
See All in Programming
Open standards for building event-driven applications in the cloud
meteatamel
0
190
VS Code をプロダクトにどう取り込むか
onomax
1
780
Build Apps for iOS, Android & Desktop in 100% Kotlin With Compose Multiplatform (mDevCamp 2024)
zsmb
0
480
Polars入門
daikikatsuragawa
1
200
Fragment Composition of GraphQL
quramy
13
1.6k
MicrosoftのPlatform Engineeringガイドを読んで実際になにかやってみた
ymd65536
1
530
GNU Makeの使い方 / How to use GNU Make
kaityo256
PRO
12
4.2k
サイコロで理解する統計的仮説検定の考え方
tatamiya
4
1.1k
Node.js v22 で変わること
yosuke_furukawa
PRO
12
4k
Scalable Customer Journey Orchestration (CJO)
lewuathe
0
450
大規模UIKitベースアプリへのTCAの段階的導入/gradual-adoption-of-tca-in-a-large-scale-uikit-based-app
takehilo
2
210
Try creating your own orderedmap
kazamori
1
260
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
782
250k
The Cult of Friendly URLs
andyhume
74
5.7k
Building Adaptive Systems
keathley
32
1.9k
A Philosophy of Restraint
colly
197
16k
Designing for Performance
lara
601
67k
The Mythical Team-Month
searls
217
42k
How to train your dragon (web standard)
notwaldorf
75
5.2k
ParisWeb 2013: Learning to Love: Crash Course in Emotional UX Design
dotmariusz
104
6.6k
Build The Right Thing And Hit Your Dates
maggiecrowley
25
2k
Building Effective Engineering Teams - LeadDev
addyosmani
32
1.9k
Being A Developer After 40
akosma
67
580k
How GitHub Uses GitHub to Build GitHub
holman
468
290k
Transcript
『Learning Domain-Driven Design』 📚 輪読会 #1🐒 株式会社Showcase Gig 鈴木
慎一郎(@suzushin54) #lddd_rindoku 2022/03/24
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
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
Foreword - 前書き (1/4) ❏ ドメイン駆動設計(以下、DDD ) は、ビジネスの観点からソフトウェアを構築するための協調的 なアプローチ ❏
ドメインと、その問題を対象とするプラクティスを提供するもの ❏ 2003年に Eric Evans が発表した書籍からはじまったコンセプト ❏ DDD Community では “The Blue Book” として親しまれている 『Domain-Driven Design: Tackling Complexity in the Heart of Software』 『エリック・エヴァンスのドメイン駆動設計 ソフトウェアの核心にある複雑さに立ち向かう』 4
Foreword - 前書き (2/4) ❏ DDD の目的は、複雑さに取り組み、明確な道筋を示すこと ❏ 開発者だけがソフトウェア開発に関わっているわけではないことを思い出させてくれる
❏ ドメインエキスパートは、ドメインに対して重要な理解をもたらす存在である ❏ 戦略的設計 (strategic design) ❏ ビジネスの問題 (domain) を理解すること ❏ 小さく、解決可能で、互いに関連した問題に分解する ❏ ビジネス側の人間とはドメインの言語でコミュニケーションする ❏ 戦術的設計 (tactical design) ❏ 戦略的設計で発見したことをアーキテクチャと実装に落とし込む ❏ ここでもドメインの言語でコミュニケーションする 5
Foreword - 前書き (3/4) ❏ Eric Evans さんは 2019年の Explore
DDD の基調講演に登壇 ❏ DDD を進化させ続けること ❏ 実践だけでなくアイディアを共有する方法を見つけること、を呼びかけた Explore DDD Conference http://exploreddd.com/ 6
Foreword - 前書き (4/4) ❏ 本書は新参者向けではあるが、経験豊富な実践者にとっても読み応えがあるもの ❏ DDD を始める時には混乱することがあるが、本書はシンプルにトピックを紹介している
❏ 本書の後半では、EventStorming など DDD から発展したプラクティスも紹介 ❏ マイクロサービスや、よく知られた設計パターンと統合できるかについても論じている 7
Preface ❏ 初めて Software Engineering の仕事に就いた日のことを鮮明に覚えている ❏ “Real Programmer”
になってコードを書きたいと思っていた ❏ そこで同僚が手取り足取り教えてくれた “でも、ビジネスロジック層はどうするんですか?” “あれは簡単だよ。ここにビジネスロジックを実装するんだ” “でもビジネスロジックって何ですか?” “要件を実現するために必要なループや if-else 文のことだよ” ❏ その日から、ビジネスロジックとは何かを知る旅に出た ❏ 答えは、『Domain-Driven Design』にあった ❏ やはりビジネスロジックは重要で、ソフトウェアの心臓部だった 8
Preface - この本を書いた理由 ❏ 様々な会社で同僚に DDD を紹介したり、レクチャーしたりしてきた ❏ 自身の理解を深めるだけでなく、原理やパターンの説明の最適化に役立った
❏ 私はエリヤフの仕事と教えの大ファン。彼はよく次のように言っていた “どんなに複雑なシステムでも、正しいアングルから見れば本質的にはシンプルである” ❏ DDD を教える過程で、DDD の本質的なシンプルさを明らかにしようとしてきた ❏ 本書はその成果である ❏ この本の目的は、DDD を民主化すること ❏ つまり、理解しやすく採用しやすいものにすること https://ja.wikipedia.org/wiki/エリヤフ・ゴールドラット 世界的ベストセラー『ザ・ゴール』で知られるイスラエルの経営学の第一人者 9
Preface - この本を読むべき人 ❏ あらゆるレベルの Software Engineer にとって有用である ❏
Software Architect にとっては、さらに重要なもの ❏ 大規模なシステムをサブシステムやマイクロサービスなどのコンポーネントに 分解、統合してシステムを形成する設計をするために役立つ ❏ ただ設計するだけでなく、ビジネスの変化に合わせて進化させる方法も解説している ❏ 設計を正常な状態に保ち、時間の経過とともに 大きな泥団子 になるのを防ぐ 10
Preface - この本のナビゲーション ❏ 4つのパートで構成されている 1. 戦略的設計 大規模なソフトウェア設計のためのツールやテクニックを紹介 2.
戦術的設計 コードにフォーカスし、ビジネスロジックを実装する方法を紹介 3. DDD の実践 実際のプロジェクトで DDD を導入するためのテクニックと戦略を解説 4. 他の方法論やパターンとの関係 DDD と、方法論やパターンとの関係を議論する 11
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
Preface - ドメイン例 (WolfDesk) ❏ ヘルプデスクチケット管理システムをサービスとして提供している ❏ 競合他社とは異なる支払いモデルを採用している
❏ ユーザ数の課金ではなく、サポートチケット数で課金される ❏ 最低利用料金はなく、ボリュームディスカウントが自動適用される ❏ 月500件以上で10%、750件以上で20% …etc ❏ 悪用防止のためのチケットライフサイクル アルゴリズムがある ❏ “サポート・オートパイロット”機能があり、履歴から解決策を提示したりする ❏ 認証認可のためのセキュリティ標準。既存のユーザ管理システムとSSOを設定可能 ❏ サポートエージェントのシフト入力が可能 13
Introduction(1/2) ❏ Software Engineering は難しい ❏ 新しい言語、技術、成功のためには学び続けないといけない ❏ しかし毎週新しい
JavaScript の Framework を学ぶことよりも、 新しいビジネスドメインを学ぶことの方がずっとチャレンジングである ❏ ビジネスドメインを把握できていないと、実装は最適なものではなくなる ❏ 調査によると、ソフトウェア開発プロジェクトの70%はQCDを満たさない(=失敗) ❏ ソフトウェア危機(Software Crisis)という言葉まで生まれた ❏ それに対して、数多くのアプローチや方法論が導入されてきた ❏ Agile, XP, TDD, 高級言語, DevOps …etc ❏ しかし、状況はあまり変わっていない 14
Introduction(2/2) ❏ なぜプロジェクトはうまくいかないのか? ❏ 研究によると、“コミュニケーション”という共通のテーマがありそう ❏ 不明瞭な要求、プロジェクトゴール、チーム間の調整 …etc
❏ そのため、新たなコミュニケーション機会やプロセスの導入などで改善を 試みてきたが、プロジェクトの成功率はあまり変わらなかった ❏ DDD は、プロジェクトの失敗原因に対して、異なるアングルから取り組むもの ❏ それが、戦略的ツールと、戦術的ツール ❏ 設計とビジネス戦略の結びつきが強いほど、将来のビジネス要求に合わせてシステムをメンテ ・進化させやすくなる ❏ Let’s start our DDD journey ! 15