DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
?
29 likes?49,942 views
質問への回答(35件)を、ブログにまとめているのでこちらご覧ください https://little-hands.hatenablog.com/entry/2019/08/31/genba_de_ddd 「Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！ コラボカンファレンス」登壇資料 ブログ：https://little-hands.hatenablog.com/ Twitter：https://twitter.com/little_hand_s 質問箱：https://peing.net/ja/little_hands
DDDのモデリングとは何なのか、 そしてどうコードに落とすのか
- 2. 自己紹介 ● 松岡 幸一郎 (@little_hand_s) ● DDD community jp主催 ● DDD周りの話をするブログ書いてます 2
- 3. 質問受け付けます ● app.sli.doにアクセス ● codeに「lh20190831」を入力 ● 質問を追加 or 既存の質問に投票 3
- 4. 今日解決したいこと 4
- 8. 今日話すこと 1. DDDにおけるモデリングとは 2. どうやってモデリングするか 3. どうやってコードに落とすか 4. どうやって現場で実践するか 8
- 13. モデルとは？に対する様々な答え ● DBA 「DBのテーブルのこと」 ● サーバーサイドエンジニア 「テーブルに対応したオブジェクトのこと」 ● 機械学習エンジニア 「数式のこと」 13
- 15. 参考情報：DDD Reference DomainLanguage.comにあるDDDのエッセンスの要約版 Evans本よりだいぶまとまっているので、定義などに迷ったらまずこちらを参考に 15
- 16. ● 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
- 17. 言葉の定義 ● 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
- 21. モデルの区別 ● ドメインモデル： ドメインの問題を解決するためのモデル ● データモデル： データベースに何かを永続化するためのモデル → これらは別のものであり、明確に区別する必要がある 21
- 22. モデルの区別 ● ドメインモデル： ドメインの問題を解決するためのモデル ● データモデル： データベースに何かを永続化するためのモデル → これらは別のものであり、明確に区別する必要がある →まずはドメインモデルを作り、 その永続化を実現するためのデータモデルを作る という形で共存する 22
- 28. ドメインモデリングの方法 ● 一つに決まった方法はない ○ 体系化された手法の例 ■ リレーションシップ駆動要件分析(RDRA) ■ ユースケース駆動分析設計 ● シンプルな例をご紹介 ユースケース図 / ドメインモデル図によるモデリング ● タスク管理アプリケーションにおける事例で説明する 28
- 29. ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ● 次に続くドメインモデリングの範囲も決める 29
- 30. ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ● 次に続くドメインモデリングの範囲も決める 30
- 31. ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ● 次に続くドメインモデリングの範囲も決める 今回のモデリングのス コープ 31
- 33. ● ユースケースの具体化?言語化 ○ 具体化しないと、どのようなモデルを作ればいいかわからない ○ 「いち作業者として、自分のタスクを管理したい」のか 「管理者として、複数作業者のタスク状況を管理したい」のか それによって「タスク」のドメインモデルは違うものになる ● ドメインモデル図作成作業の範囲を狭める ○ ユースケース図を作る必要性 33
- 34. ● ユースケースの具体化?言語化 ○ 具体化しないと、どのようなモデルを作ればいいかわからない ○ 「いち作業者として、自分のタスクを管理したい」のか 「管理者として、複数作業者のタスク状況を管理したい」のか それによって「タスク」のドメインモデルは違うものになる ● ドメインモデル図作成作業の範囲を狭める ○ ドメインモデル図作成をしていると、いろんな要素が思い浮かんでくる ○ 範囲を限定して、限られた時間でまとまった成果を出せるようにする ユースケース図を作る必要性 34
- 35. ドメインモデル図 ● クラス図の簡易版 ● メソッド(振る舞い)は不要 ● 属性も代表的なものだけでOK ● 業務の「ルール?制約」(=ドメイン知識) を吹き出しで記述する ● 集約の範囲を明記する 35
- 36. 集約について ● 集約＝「必ず守りたい強い整合性を持ったオブジェクトのまとまり」 ● 必ずまとめて取得して、まとめて更新する単位 ● 今回の発表では集約の検討が必要な事例は示せないが、 「このタイミングで集約設計する」ということを覚えておいてください 36
- 38. ドメインモデル図 38
- 40. まず、形から入る ● レイヤーを定義して「このレイヤにはこういうクラスを作る」というのを決める ● その決まりの上で、とりあえず動くものを書く ● 参考：新卒にも伝わるドメイン駆動設計のアーキテクチャ説明 40
- 50. ● 修正前のクラスを再度確認 ● このクラスに、吹き出しの知識を移譲する Taskクラス -Before 50
- 51. Taskクラス -After (1/3) コンストラクタ ● コンストラクタにタスク作成時の知識を移譲 タスクは未完了状態で作成 される 51
- 52. Taskクラス -After (2/3) 延期メソッド ● 延期メソッドに延期時の知識を移譲 タスクは3回だけ、 1日ずつ延期することができる。 52
- 53. Taskクラス -After (3/3) Setter ● Setterがなくなっているので、公開しているメソッド以外で操作できない 53
- 58. ● お手本コードを作る ○ ApplicationService(UseCase)、Entity、Repository??? ● お手本に倣ってコードを書くようにチーム展開する ○ この段階では軽量DDDでも全然OK ● 書くのになれたら、ドメインモデリングしてみる ● ドメインモデル図を元にリファクタリングしていく DDD導入の進め方 58
- 62. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかない コーディング モデリング 62
- 63. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ● 両方交互に経験値をためながら上達していくしかない ● どちらからこのサイクルを初めてもよいが、 コーディングの方がとっつきやすい コーディング モデリング 63
- 65. 質問箱で質問募集しています ● 質問いただければ回答します ● https://peing.net/ja/little_hands ● 「質問箱 little_hands」で検索 65