$30 off During Our Annual Pro Sale. View Details »
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Learning DDD輪読会#1
Search
suzushin54
March 24, 2022
Programming
2
1k
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
4
3k
Learning DDD輪読会#15 / Learning DDD Book Club #15
suzushin54
1
250
認知的複雑度から見るGo言語のイベントソーシング実装 / Event Sourcing with Go
suzushin54
8
5.1k
Learning DDD輪読会#9 / Learning DDD Book Club #9
suzushin54
0
280
Learning DDD輪読会#4 / Learning DDD Book Club #4
suzushin54
1
740
複数の境界づけられたコンテキストにおける共通ロジックの扱いについて / Handling common logic in multiple contexts
suzushin54
1
1.9k
Other Decks in Programming
See All in Programming
StarlingMonkeyを触ってみた話 - 2024冬
syumai
2
180
社内活動の取り組み紹介 ~ スリーシェイクでこんな取り組みしてます ~
bells17
0
390
CSC305 Lecture 26
javiergs
PRO
0
120
Arm移行タイムアタック
qnighy
0
410
nekko cloudにおけるProxmox VE利用事例
irumaru
2
110
As an Engineers, let's build the CRM system via LINE Official Account 2.0
clonn
1
640
Serverless苦闘史
mosh_inc
0
150
React への依存を最小にするフロントエンド設計
takonda
21
8.9k
Seamless Flutter Native Integration: FFI & Pigeon - Dreamwalker (JaichangPark / 박제창) @FlutterKaigi2024
itsmedreamwalker
0
120
14 Years of iOS: Lessons and Key Points
seyfoyun
1
690
似たもの同士のPerlとPHP
uzulla
1
110
DevTools extensions で 独自の DevTool を開発する | FlutterKaigi 2024
kokiyoshida
0
450
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
45
6.9k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.7k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
6
490
How to Think Like a Performance Engineer
csswizardry
21
1.2k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
247
1.3M
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
17
2.2k
Building Applications with DynamoDB
mza
91
6.1k
Building Adaptive Systems
keathley
38
2.3k
Visualization
eitanlees
145
15k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
132
33k
How STYLIGHT went responsive
nonsquared
95
5.2k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
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