DDDモデリングとは何なのか、そしてどうコードに落とすのか

Slide 1

Slide 1 text

DDDのモデリングとは何なのか、そしてどうコードに落とすのか 2019.8.31 松岡幸一郎 (@little_hand_s) 1

Slide 2

Slide 2 text

自己紹介 ● 松岡幸一郎 (@little_hand_s) ● DDD community jp主催 ● DDD周りの話をするブログ書いてます 2

Slide 3

Slide 3 text

質問受け付けます ● app.sli.doにアクセス ● codeに「lh20190831」を入力 ● 質問を追加 or 既存の質問に投票 3

Slide 4

Slide 4 text

今日解決したいこと 4

Slide 5

Slide 5 text

今日解決したいことモデリングってどうやるのかわからない 5

Slide 6

Slide 6 text

今日解決したいことモデリングとコードがどう繋がるのかわからない 6

Slide 7

Slide 7 text

今日解決したいことどうやって現場で実践するのかわからない 7

Slide 8

Slide 8 text

今日話すこと 1. DDDにおけるモデリングとは 2. どうやってモデリングするか 3. どうやってコードに落とすか 4. どうやって現場で実践するか 8

Slide 9

Slide 9 text

1. DDDにおけるモデリングとは 9

Slide 10

Slide 10 text

● まず、モデルとは？ DDD文脈での定義 10

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

● DBA 「DBのテーブルのこと」 ● サーバーサイドエンジニア「テーブルに対応したオブジェクトのこと」モデルとは？に対する様々な答え 12

Slide 13

Slide 13 text

モデルとは？に対する様々な答え ● DBA 「DBのテーブルのこと」 ● サーバーサイドエンジニア「テーブルに対応したオブジェクトのこと」 ● 機械学習エンジニア「数式のこと」 13

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

言葉の定義 ● Domain: A sphere of knowledge, inﬂuence, or activity. The subject area to which the user applies a program is the domain of the software. ● ドメイン：ソフトウェアで問題解決しようとする対象ざっくり意訳 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

Slide 22

Slide 22 text

モデルの区別 ● ドメインモデル：ドメインの問題を解決するためのモデル ● データモデル：データベースに何かを永続化するためのモデル → これらは別のものであり、明確に区別する必要がある →まずはドメインモデルを作り、　その永続化を実現するためのデータモデルを作る　という形で共存する 22

Slide 23

Slide 23 text

DDDアプローチの全体像ドメイン問題 23

Slide 24

Slide 24 text

DDDアプローチの全体像ドメインモデルドメイン問題 24

Slide 25

Slide 25 text

DDDアプローチの全体像ドメインモデルドメインソフトウェア問題 25

Slide 26

Slide 26 text

DDDアプローチの全体像ドメインモデルドメインソフトウェア問題解決 26 参考：ドメイン駆動設計は何を解決しようとしているのか

Slide 27

Slide 27 text

2.どうやってモデリングするのか 27

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ● 次に続くドメインモデリングの範囲も決める 29

Slide 30

Slide 30 text

ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ● 次に続くドメインモデリングの範囲も決める 30

Slide 31

Slide 31 text

ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ● 次に続くドメインモデリングの範囲も決める今回のモデリングのスコープ 31

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

● ユースケースの具体化・言語化 ○ 具体化しないと、どのようなモデルを作ればいいかわからない ○ 「いち作業者として、自分のタスクを管理したい」のか「管理者として、複数作業者のタスク状況を管理したい」のかそれによって「タスク」のドメインモデルは違うものになる ● ドメインモデル図作成作業の範囲を狭める ○ ユースケース図を作る必要性 33

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

ドメインモデル図 38

Slide 39

Slide 39 text

3.どうやってコードに落とすか 39

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

● ドメインモデル図の知識がApplication層のクラスに書かれているタスクは未完了状態で作成されるタスクは3回だけ、 1日ずつ延期することができる。 48

Slide 49

Slide 49 text

● ドメインモデル図の知識をDomain層のクラス、特に吹き出しが書かれたオブジェクトに写すタスクは未完了状態で作成されるタスクは3回だけ、 1日ずつ延期することができる。 49

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

Taskクラス - After (1/3) コンストラクタ ● コンストラクタにタスク作成時の知識を移譲タスクは未完了状態で作成される 51

Slide 52

Slide 52 text

Taskクラス - After (2/3) 延期メソッド ● 延期メソッドに延期時の知識を移譲タスクは3回だけ、 1日ずつ延期することができる。 52

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

4.どうやって現場で実践するか 57

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

なぜお手本コード展開から入るのか ● 「原理を理解して実践」より、「お手本を元に展開」の方が圧倒的に難易度が低いため ● 「どういうコードに落としこまれるのか」がイメージできてからの方が、ドメインモデリングしやすいため 59

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもないコーディングモデリング 61

Slide 62

Slide 62 text

上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかないコーディングモデリング 62

Slide 63

Slide 63 text

上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかない ● どちらからこのサイクルを初めてもよいが、コーディングの方がとっつきやすいコーディングモデリング 63

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

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