ドメイン駆動設計モデリング_実装入門勉強会_2020.3.8

2020.3.8
松岡幸一郎 (@little_hand_s)
1
ドメイン駆動設計
モデリング/実装入門勉強会

自己紹介
● 松岡幸一郎 (@little_hand_s)
● DDD community jp主催
● DDD周りの話をするブログ書いてます
● WEB+DB PRESS 2019年10月号特集「体験ドメイン駆動設計」執筆
2

本日の趣旨
3
● 「ドメイン駆動設計モデリング/実装ガイド」
技術書典8向けに執筆
● 発売記念として、本書の一部内容+αを
オンライン講義形式で解説します

● オンラインで既存のオフライン勉強会をどの程度代替できるか、
の検証としての試み
オンライン勉強会というチャレンジ
オフライン勉強会
● 前に立って発表
● Twitterのハッシュタグツイート
● Sli.doによる質疑応答
● 登壇後の個別質問
4
オンライン勉強会
●
●
●
●

5
● YouTube Liveによる配信
●
●
●

6
●

7
● YouTube Liveのチャットによる質問
やりとり

質問受け付けます
● sli.doで質問受け付けます
○ https://app.sli.do/event/imvxc56h にアクセス
○ 質問を追加 or 既存の質問に投票
8

質問受け付けます
● sli.doで質問受け付けます
○ https://app.sli.do/event/imvxc56h にアクセス
○ 質問を追加 or 既存の質問に投票
● ツイートは通常のイベントのようにお願いします
○ Twitterハッシュタグは #ddd_guide
○ YouTube Live上のコメントもOK
9

不慣れな点も多々ありますが、お付き合いお願いいたします
10

予算策定のGitHub を開発 
実績/調達  技術スタック 
シンガポールの 
VCから調達

ログラスDDD勉強会を開催しました！｜坂本龍太: Loglass｜note

● DDD概要
○ DDDとは
○ モデルとは
○ 良いモデル、良くないモデル
話す内容
16

● DDD概要
○ DDDとは
○ モデルとは
● モデリングから実装まで
○ ドメインモデリングの方法
○ ドメインモデルを実装に落とす
○ ライブコーディング
話す内容
17

● DDD概要
○ DDDとは
○ モデルとは
● プロジェクトへの導入方法のススメ
話す内容
18

● DDD概要
○ DDDとは
○ モデルとは
● 「ドメイン駆動設計モデリング/実装ガイド」他の章の紹介
話す内容
19

● DDD概要
○ DDDとは
○ モデルとは
話す内容
20
1章より

● DDD概要
○ DDDとは
○ モデルとは
話す内容
21
1章より
2章より

● DDD概要
○ DDDとは
○ モデルとは
● 「ドメイン駆動設計モデリング/実装ガイド」他の章の紹介　
話す内容
22
1章より
2章より
3~11章

資料公開
● サンプルコード
○ GitHubにて公開中
● 資料
○ こちらにて公開中
23

● DDDの概要、開発の流れを理解する
今日のゴール

● DDD、そんなに難しくないと思えるようになる
今日のゴール

今日のゴール
● DDD、そんなに難しくないと思えるようになる
● DDDについてもっと知りたくなる

DDDとは
● DDDとは
抽象的にいうと「ソフトウェア開発手法の一つ」である

● そもそも、ソフトウェアはなんのために作るのか？

● ソフトウェアを適用する対象の何らかの問題を解決するため

● この「ソフトウェアで問題解決しようとする対象」を「ドメイン」と呼ぶ

● DDD：
DomainDrivenDesign(ドメイン駆動設計)の略
● DDD Referenceより
"多くのプロジェクトは、モデリングを行っても
最終的に大きな利益を得られないまま終わります。
DDDは、モデリングから劇的な利益を得られたプロジェクトから、
成功するパターンを抽出します。”

(注：DDD Reference)
DomainLanguage.comにあるDDDのエッセンスの要約版
Evans本よりだいぶまとまっているので、定義などに迷ったらまずこちらを参考に

● DDDは
「ドメインモデリングによってソフトウェアの価値を高める」
ことを目指す。

あれ？
アーキテクチャ、コード品質の話が出てこない？

「コード品質を上げること」を目的としてDDDを導入検討されることが多いですが
DDDの目的はコード品質のさらに先にあるのです

では、コード品質との関係はどうなるのか？
今日はそのつながりも含んだ全体像を示します。

● 「モデル」とはなんでしょうか？
モデルって何？

モデルとは？に対する様々な答え
● DBA
「DBのテーブルのこと」
43

● DBA
● サーバーサイドエンジニア
「テーブルに対応したオブジェクトのこと」
44

● DBA
● サーバーサイドエンジニア
「テーブルに対応したオブジェクトのこと」
● 機械学習エンジニア
「数式のこと」
45

モデルとは？
● 「モデル」という言葉は文脈によって大きく違う使われ方をする
● 言葉の定義をしましょう

● model:
A system of abstractions that describes selected aspects of a domain and can
be used to solve problems related to that domain
● モデル：問題解決のために、物事の特定の側面を抽象化したもの
DDD文脈での定義
ざっくり意訳
47

モデルの区別
● ドメインモデル：
● データモデル：
48

モデルの区別
ドメインの問題を解決するためのモデル
49

モデルの区別
データベースに何かを永続化するためのモデル
50

モデルの区別
データベースに何かを永続化するためのモデル
→ これらは別のものであり、明確に区別する必要がある
51

● モデル：問題解決のために、物事の特定の側面を抽象化したもの
→ 抽象化とは何でしょうか？
DDD文脈での定義
52

例：履歴書現実には数多くの要素がある
・名前、経歴、志望理由
・写真

・写真
・筆跡、筆圧
・紙質、折れ具合

・写真
・筆跡、筆圧
・紙質、折れ具合
・履歴書のメーカー
・履歴書の値段
・履歴書を書いた時の気持ち
・：

現実世界の全ての要素をソフトウェアに落とし込むことは不可能

→ 必要な要素はモデルに取り込みたい
→ 不要な要素はモデルに取り込みたくない

→ 必要な要素はモデルに取り込みたい
→ 不要な要素はモデルに取り込みたくない
この選択が「抽象化」

● 良いモデルとは何か？

わかりやすいモデル、現実に即しているモデル、拡張性のあるモデル…

→問題解決ができるモデル

● 良くないモデルとは何か？

● 良くないモデルとは何か？
→問題解決ができないモデル
○ 現実に即していない
○ やりたいことができない

● 中途採用における「採用進捗」
現実世界(ドメイン) モデル

書類選考の前に面談
があるのに・・・

面接は3次、4次もある
のに・・・

のに・・・
求人関係ない応募も
許可したい・・・

のに・・・
求人関係ない応募も
許可したい・・・
運用で
カバー

モデルが良くなくて問題解決できない

運用でカバーできればまだマシ、
売れなければプロダクトがなくなる

● もしも、このソフトウェアが

● DDDの実装パターンを的確に使っている
● コードの可読性、拡張性が完璧
● テストも完璧で、バグが全くでない

　ものだったとしたら、高い価値を生み出せるか？

　ものだったとしたら、高い価値を生み出せるか？
→ NO！！

● モデルがイケてないと、
その後の実装がどんなに素晴らしくても良いソフトウェアにはならない

● 良いモデルを作るにはどうすれば良いか？

→ドメインに詳しい人から知識を得る

→運用した知見をモデルにフィードバックして改善する

→運用した知見をモデルにフィードバックして改善する
→モデルは最初から完成しない、改善していくもの
　(DDDとして重要なスタンス)

● モデルは最初から完成しない、改善していくもの
モデルコード

● コードとモデルが乖離すると…
モデルコード

○ モデルの更新をコードに正しく反映できているかわからなくなる
モデルコード

○ モデルの更新をコードに正しく反映できているかわからなくなる
○ モデルからコードを理解しにくくなる
モデルコード

● モデルの更新をコードに正しく反映できているかわからない
● コードからモデルを理解しにくい
モデルとコードが乖離すると発生する問題

→意図していない実装(=バグ)を産みやすくなる

→意図していない実装(=バグ)を産みやすくなる
→ドメインに対する理解もできない
→モデルは改善されない
→ソフトウェアの価値を高めにくくなる

● コードとモデルが乖離すると問題が発生する
● モデルは継続的に改善したい
問題と対策

→モデルそのまま表現したコードとなるのが望ましい
問題と対策

→「オブジェクト」でモデルを表現する
問題と対策

→コードにも継続的に反映しないと行けない
→頻繁な変更に耐えうるには、拡張性の高い設計が必要
問題と対策

→これはソフトウェアとしては非常に高い要求
問題と対策

→これはソフトウェアとしては非常に高い要求
→そこで生まれたのがEntityやRepositoryなどのデザインパターン
問題と対策

● 軽量DDD：DDDの実装パターンだけ取り入れること
軽量DDDとは

● 拡張性の高いベストプラクティスを取り入れる
→それだけでも十分価値がある
軽量DDDとは

● コード品質をあげると、ようやくモデリングする余地が生まれる
と考えることもできる
軽量DDDとは

● コード品質をあげると、ようやくモデリングする余地が生まれる
と考えることもできる
● 何の問題もない、
そこからモデリングに踏み出しましょう
軽量DDDとは

DDDのアプローチ
DDDのアプローチの全体像

モデルがイケてないと、
実装がどんなに素晴らしくても良いソフトウェアにはならない

モデルを継続的にソフトウェアに反映するために拡張性の高い設計をする

どうやってモデリングするのか
104

ドメインモデリングの方法
● 一つに決まった方法はない
○ 体系化された手法の例
■ リレーションシップ駆動要件分析(RDRA)
■ ユースケース駆動分析設計
● シンプルな例をご紹介
ユースケース図 / ドメインモデル図によるモデリング
● タスク管理アプリケーションにおける事例で説明する
105

ユースケース図
● ユーザーとアプリケーションの相互作用を定義する
● 一般的なUMLのものと同じ
106

107

● 次に続くドメイン図作成の範囲も決める
今回のモデリングのス
コープ
108

● ユースケースの具体化・言語化
○
● ドメインモデル図作成作業の範囲を狭める
○
ユースケース図を作る必要性
109

○ 具体化しないと、どのようなモデルを作ればいいかわからない
○ 「いち作業者として、自分のタスクを管理したい」のか
「管理者として、複数作業者のタスク状況を管理したい」のか
それによって「タスク」のドメインモデルは違うものになる
○
110

○ 具体化しないと、どのようなモデルを作ればいいかわからない
○ 「いち作業者として、自分のタスクを管理したい」のか
「管理者として、複数作業者のタスク状況を管理したい」のか
それによって「タスク」のドメインモデルは違うものになる
○ ドメインモデル図作成をしていると、いろんな要素が思い浮かんでくる
○ 範囲を限定して、限られた時間でまとまった成果を出せるようにする
111

ドメインモデル図
● クラス図の簡易版
● メソッド(振る舞い)は不要
● 属性も代表的なものだけでOK
● 業務の「ルール・制約」(=ドメイン知識) を吹き出しで記述する
● 集約の範囲を明記する
112

集約について
● 集約＝「必ず守りたい強い整合性を持ったオブジェクトのまとまり」
● 必ずまとめて取得して、まとめて更新する単位
● 今回の発表では集約の検討が必要な事例は示せないが、
「このタイミングで集約設計する」ということを覚えておいてください
113

実際のモデリング
● 最初はホワイトボードに殴り書きでOK
114

どうやってコードに落とすか
116

まず、形から入る
● レイヤーを定義して「このレイヤにはこういうクラスを作る」というのを決める
● その決まりの上で、とりあえず動くものを書く
● 参考：新卒にも伝わるドメイン駆動設計のアーキテクチャ説明
117

● 改善余地があるコードから入り、リファクタリングしていきます
説明の流れ
118

● この段階では属性の定義のみ、ドメイン知識は持っていない
Taskクラス
119

TaskApplicationSericeクラス -タスクを登録する
● ApplicationServiceクラスにタスク登録時の処理を書く
120

● 延期時の処理も同様
TaskApplicationSericeクラス -タスクを延期する
121

このコードの問題点
● 不整合なデータをいくらでも作れる
● 仕様を追いかけるのに、複数クラスをコード参照から追っていくしかない
122

ドメインモデル図の見直し
● ドメインモデル図の吹き出しの知識はどのクラスに書かれているか？
123

TaskApplicationSericeクラス -タスクを登録する
タスクは未完了状態で作成
される
124

TaskApplicationSericeクラス -タスクを延期する
タスクは3回だけ、
1日ずつ延期することができる。
125

● ドメインモデル図の知識がApplication層のクラスに書かれている
される
126

● ドメインモデル図の知識をDomain層のクラス、
特に吹き出しが書かれたオブジェクトに委譲する
される
1日ずつ延期することができる。 127

● 修正前のクラスを再度確認
● このクラスに、吹き出しの知識を委譲する
Taskクラス -Before
128

Taskクラス -After (1/3) コンストラクタ
● コンストラクタにタスク作成時の知識を移譲
される
129

Taskクラス -After (2/3) 延期メソッド
● 延期メソッドに延期時の知識を移譲
130

Taskクラス -After (3/3) Setter
● Setterがなくなっているので、公開しているメソッド以外で操作できない
131

シンプルになったApplicationServiceクラス
● ユースケース記述レベルの抽象度の高いコードのみ残る
132

この設計のメリット(1/3)
● 不整合なデータを作れないように強制できる
○ Setter非公開にしたので不整合な値をセットできない
コンパイルエラーになる
133

● 他のルールで生成・更新
されないことが確実になっている
● 1クラスに吹き出しの知識が
凝縮されている
→「このクラスだけ見れば良い」
という大きな安心感を得られる
134

● レイヤーによって書くべきことが決まっている
→コード規約の様に定めて、
　実装やレビューの時に使える
● 「俺の考えた最強の設計」同士が戦わなくて済む
135

どうやって現場で実践するか
136

● お手本コードを作る
○ ApplicationService、Entity、Repository・・・
● お手本に倣ってコードを書くようにチーム展開する
○ この段階では軽量DDDでも全然OK
● 「あれ、ドメイン層には何を書くべきなんだっけ？」
となったら、ドメインモデリングしてみる
● ドメインモデル図を元にリファクタリングしていく
DDD導入の進め方
137

● 「原理を理解して実践」より、
「お手本を元に展開」の方が圧倒的に難易度が低いため
●
●
なぜお手本コード展開から入るのか
138

● ドメイン層に何を書くべきか？という疑問を持った方が
モデリングの必要性を感じやすいため
●
139

● ドメイン層に何を書くべきか？という疑問を持った方が
モデリングの必要性を感じやすいため
● 「どういうコードに落としこまれるのか」が
イメージできてからの方が、ドメインモデリングしやすいため
140

上達のイメージ
● DDDのコーディング、モデリング共に1発では上手くできない
コーディングモデリング
141

● コーディングだけ、モデリングだけ上手くなるということもない
142

● 両方交互に経験値をためながら上達していくしかない
143

● 結局、このサイクルのどちらから入るか、という違いだけ
144

● 結局、このサイクルのどちらから入るか、という違いだけ
● コーディングと、モデリングを意識的に両方少しずつやってみるのが良い
145

まとめ
● DDDでは、「モデルを継続的に改善」「モデルの更新をソフトウェアに反映」のアプロー
チでソフトウェアの価値を高める
● モデルの更新を反映しやすいように、モデルをそのまま表現する
その際にオブジェクト指向の手法を利用する
● DDD戦術設計パターンは、保守性の高い設計のベストプラクティス
● 設計パターンの適用(軽量DDD)と、モデリングを両方使うと、
ソフトウェアの価値を高められる
● 実装と、モデリングを少しずつ着手してみよう
146

他の章にも興味を持っていただけた方は
149
「ドメイン駆動設計モデリング/実装ガイド」
boothにて販売中

質問箱で質問募集しています
● 質問いただければ回答します
● https://peing.net/ja/little_hands
● 「質問箱 little_hands」で検索
150

ご静聴ありがとうございました
151

ご静聴ありがとうございました
153

ドメイン駆動設計モデリング_実装入門勉強会_2020.3.8

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to ドメイン駆動設計モデリング_実装入門勉強会_2020.3.8

Similar to ドメイン駆動設計モデリング_実装入門勉強会_2020.3.8 (20)

Recently uploaded

Recently uploaded (10)