何がDDDをDDDにするのか / what make DDD to DDD ?

Slide 1

Slide 1 text

何が“DDD”を”DDD”にするのか 2020/01/18 学生と社会人のライトニングトーク大会 #北海道LT大会 @Philomagi 1

Slide 2

Slide 2 text

発表者 @Philomagi ● 主にフロントエンド主体のWEB系エンジニア ● ScalaとTypescriptが好き ● PHPは中々縁が切れない悪友 ○ 最近は、「然程悪いやつでもないな」と思い始めてる 2

Slide 3

Slide 3 text

概要 ● ドメイン駆動設計(DDD) ● DDDを取り巻く混乱 ● “DDD”を”DDD”足らしめるモノ ● まとめ 3

Slide 4

Slide 4 text

ドメイン駆動設計 Domain-Driven Design(DDD) 4

Slide 5

Slide 5 text

ドメイン駆動設計 5

Slide 6

Slide 6 text

DDD is 何？ 6 ● ソフトウェア設計の方法論 ● Eric Evansによる提唱 ● 「ユーザー要求の問題解決にフォーカスした設計パターン」（日本語版帯より） ● 「ドメイン駆動設計、略してDDDと呼ばれるソフトウェア開発手法がある。（中略）これをうまく使いこなせば、設計した結果が、そのソフトウェアの動作を明確に表すようになる。」(「実践ドメイン駆動設計」p.1)

Slide 7

Slide 7 text

DDDを取り巻く混乱 7

Slide 8

Slide 8 text

DDDを取り巻く混乱 8 ● 「Entity」「Value Object」「Service」を使えばDDD? ● 「Entity」(略)を使わなかったらDDDではない？ ● ドメインモデルを書いたらDDD？ ● ドメイン分析したらDDD？

Slide 9

Slide 9 text

DDDを取り巻く混乱 9 ● 「Entity」「Value Object」「Service」を使えばDDD? ● 「Entity」(略)を使わなかったらDDDではない？ ● ドメインモデルを書いたらDDD？ ● ドメイン分析したらDDD？

Slide 10

Slide 10 text

DDDとパターン 10 DDDは実装パターン集ではない ● 各種パターンは、モデルと実装を紐付けるための道具でしかない ● DDD本のパターンを一切使わないDDDも、原理上は考え得る

Slide 11

Slide 11 text

DDDとドメイン/ドメインモデル 11 ドメイン/ドメインモデルはDDD固有の概念ではない ● ドメイン/ドメインモデルは、DDD以前から存在し、かつDDD 以外でも有効な概念 ● ドメイン/ドメインモデルはDDDと他の方法論を区別する基準にはならない ● 故に、ドメイン/ドメインモデルを考えればDDDになるのでもない

Slide 12

Slide 12 text

何が”DDD”なのか？ 12 「DDDって何をどうすればDDDなの？」「自分たちのやり方はDDDなの？」

Slide 13

Slide 13 text

脱線：ドメイン・DDD・「コスト」 13 ● ドメイン = 問題領域。ソフトウェアで解決したい問題。 ● ドメインの分析と理解は、DDDであろうとなかろうと、ソフトウェア開発にとって一般に重要な課題。 ● 「DDDは高コスト」→ そこで言う「コスト」は何か？ ● ドメインの分析・理解を指して「コスト」と語るなら、それはDDDでなくても払うべきコスト。 ● 「DDDを使わない」は「ドメインの分析・理解を省略する」と同義ではないし、省略の理由にもならない

Slide 14

Slide 14 text

何が”DDD”を”DDD”足らしめるのか 14

Slide 15

Slide 15 text

何が”DDD”を”DDD”足らしめるのか 15 換言すれば DDDで外してはいけない核心は何か DDDと他の方法論の決定的な違いは何か

Slide 16

Slide 16 text

何が”DDD”を”DDD”足らしめるのか 16 ❌ Entity等のパターン ○ 単なる道具の一種であり、DDDの構成要件でも、DDD固有の概念でもない ❌ ドメインモデル ○ DDD固有の概念でなく、DDD以外でも利用可能 ❌ ドメイン分析 ○ DDD固有の概念でなく、ソフトウェア開発一般で必要かつ重要なプロセス

Slide 17

Slide 17 text

何が”DDD”を”DDD”足らしめるのかこのスライドでは ● ドメインに基づく概念/実装の単一モデル ● 単一モデルを介したドメイン-ソフトウェア間の相互フィードバックの実践によって「DDDが成立する」と考える 17

Slide 18

Slide 18 text

ドメインに基づく概念/実装の単一モデル 18 業務知識業務フローステークホルダー課題制約ドメイン

Slide 19

Slide 19 text

ドメインに基づく概念/実装の単一モデル 19 業務知識業務フローステークホルダー課題制約ドメインモデル

Slide 20

Slide 20 text

単一モデルを介したコミュニケーション 20

Slide 21

Slide 21 text

単一モデルを介したドメイン-ソフトウェア間の相互フィードバック 21 ドメインソフトウェア XにはX’とX’’の他に X’’’があります XはYの他にZ でも必要です X X’’ Y X’

Slide 22

Slide 22 text

単一モデルを介したドメイン-ソフトウェア間の相互フィードバック 22 ドメインソフトウェア X X’’ Y X’ X’’ Z フィードバックに基づくモデル更新

Slide 23

Slide 23 text

単一モデルを介したドメイン-ソフトウェア間の相互フィードバック 23 ドメインソフトウェア X X’’ Y X’ X’’ Z モデル更新に伴う実装の更新

Slide 24

Slide 24 text

単一モデルを介したドメイン-ソフトウェア間の相互フィードバック 24 ドメインソフトウェア X X’’ Y X’ X’’ Z Xを具体的にどうするか、YとZでそれぞれルール同じ？

Slide 25

Slide 25 text

単一モデルを介したドメイン-ソフトウェア間の相互フィードバック 25 ドメインソフトウェア X X’’ Y X’ X’’ Z Xルールフィードバックに基づくモデル更新

Slide 26

Slide 26 text

単一モデルを介したドメイン-ソフトウェア間の相互フィードバック 26 ドメインソフトウェア X X’’ Y X’ X’’ Z Xルールそうですね、そのルールはZと普段呼んでいます

Slide 27

Slide 27 text

単一モデルを介したドメイン-ソフトウェア間の相互フィードバック 27 ドメインソフトウェア X X’’ Y X’ X’’ Z Z フィードバックに基づくモデル更新

Slide 28

Slide 28 text

単一モデルを介したドメイン-ソフトウェア間の相互フィードバック 28 ドメインソフトウェア X X’’ Y X’ X’’ Z Z モデル更新に伴う実装の更新

Slide 29

Slide 29 text

単一モデルを介したドメイン-ソフトウェア間の相互フィードバック 29 ソフトウェアドメイン単一モデル

Slide 30

Slide 30 text

ドメイン駆動設計(日本語版) p.510より本書にあるテクニックをすべて採用するプロジェクトなどないだろう。それでも、ドメイン駆動設計を真剣に行っているプロジェクトはすべて、何らかのかたちでそれとわかるようになる。決定的な特徴は、対象となるドメインを理解し、その理解をソフトウェアにおいて具現化することを重視することにある。 - 「エリック・エヴァンスのドメイン駆動設計」 p.510 30

Slide 31

Slide 31 text

何が”DDD”を”DDD”足らしめるのか ● ドメインに基づく概念/実装の単一モデル ● 単一モデルを介したドメイン-ソフトウェア間の相互フィードバックの実践によって、「対象となるドメインを理解し、その理解をソフトウェアにおいて具現化する」こと。 31

Slide 32

Slide 32 text

まとめ 32

Slide 33

Slide 33 text

何が”DDD”を”DDD”足らしめるのか ● パターンやモデルそのものは、DDDの根幹ではない ● “DDD”を”DDD”足らしめるのは ○ ドメインに基づく単一モデル ○ 単一モデルを介した相互フィードバック ○ ↑の実践によるドメインの理解と、その理解が反映されたソフトウェア 33

Slide 34

Slide 34 text

最後に 34 ● 具体的なHowだけでなく、根幹にある思想・理論 = Whyもちゃんと考えてみる。 ● Whyを理解してれば、広く応用が効く。　　Howだけだと、違うケースに対応し難い。 ● Whyを考えると、視点・考え方が広がる。

Slide 35

Slide 35 text

参考にした資料 35 ● エリック・エヴァンスのドメイン駆動設計 (Eric Evans) ● 実践ドメイン駆動設計 (Vaughn Vernon) ● 意訳Domain-Driven Design (@hirodoragon112 さん) ○ 「単一モデルを介しての相互フィードバック」は、こちらの資料の議論を基としています

Slide 36

Slide 36 text

ご清聴ありがとうございました 36