Download as PDF, PPTX
Uploaded byKoichiro Matsuoka
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
商品リンクはこちら https://little-hands.booth.pm/items/1835632 DDDはドメインモデリングを通じてソフトウェアの価値を高めようとする設計・開発手法です。 新しく得られたモデルに関する知見を頻繁にコードに落とし込む必要があるのですが、 それはソフトウェアにとっては非常に高い要求をしていることになります。 そこでDDDでは、オブジェクト指向の手法を利用して、メンテナブルで、拡張性の高いコードを書くことを目指しています。 このセッションでは、DDDではモデリング結果をどのようにコードに落とし、どのような利益を得られるのかを、具体的なコードを交えながら解説します。
![ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]](https://cdn.slidesharecdn.com/ss_thumbnails/2022-220117111455-thumbnail.jpg?width=640&height=640&fit=bounds)
DDDはオブジェクト指向を利用してどのようにメンテナブルなコードを書くか
- 1. Object-Oriented Conference 2020 DDDはオブジェクト指向を利用して どのようにメンテナブルなコードを書くか 2020.2.16 松岡幸一郎 (@little_hand_s) 1
- 2. 自己紹介 ● 松岡 幸一郎(@little_hand_s) ● DDD community jp主催 ● DDD周りの話をするブログ書いてます ● 技術書典8で「ドメイン駆動設計 モデリング/実装ガイド」発売予定 2
- 3. 質問受け付けます ● app.sli.doにアクセス ● codeに「ooc_matsuoka」を入力 ●質問を追加 or 既存の質問に投票 3
- 4.
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12. ● DDD： DomainDrivenDesign(ドメイン駆動設計)の略 ● DDDReferenceより "多くのプロジェクトは、モデリングを行っても 最終的に大きな利益を得られないまま終わります。 DDDは、モデリングから劇的な利益を得られたプロジェクトから、 成功するパターンを抽出します。”
- 13.
- 14. ● DDD： DomainDrivenDesign(ドメイン駆動設計)の略 ● DDDReferenceより "多くのプロジェクトは、モデリングを行っても 最終的に大きな利益を得られないまま終わります。 DDDは、モデリングから劇的な利益を得られたプロジェクトから、 成功するパターンを抽出します。”
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23. モデルとは？に対する様々な答え ● DBA 「DBのテーブルのこと」 ● サーバーサイドエンジニア 「テーブルに対応したオブジェクトのこと」 ●機械学習エンジニア 「数式のこと」 23
- 24.
- 25. ● model: A systemof abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain ● モデル：問題解決のために、物事の特定の側面を抽象化したもの DDD文脈での定義 ざっくり意訳 25
- 26.
- 27.
- 28.
- 29. モデルの区別 ● ドメインモデル： ドメインの問題を解決するためのモデル ● データモデル： データベースに何かを永続化するためのモデル →これらは別のものであり、明確に区別する必要がある 29
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42. ● 良いモデルとは何か？ わかりやすいモデル、現実に即しているモデル、拡張性のあるモデル… →問題解決ができるモデル ● 良くないモデルとは何か？ →問題解決ができないモデル ○現実に即していない ○ やりたいことができない
- 43.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.
- 50.
- 51.
- 52.
- 53. ● もしも、このソフトウェアが ● DDDの実装パターンを的確に使っている ●コードの可読性、拡張性が完璧 ● テストも完璧で、バグが全くでない
- 54. ● もしも、このソフトウェアが ● DDDの実装パターンを的確に使っている ●コードの可読性、拡張性が完璧 ● テストも完璧で、バグが全くでない ものだったとしたら、高い価値を生み出せるか？
- 55. ● もしも、このソフトウェアが ● DDDの実装パターンを的確に使っている ●コードの可読性、拡張性が完璧 ● テストも完璧で、バグが全くでない ものだったとしたら、高い価値を生み出せるか？ → NO！！
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64.
- 65. ● コードとモデルが乖離すると… ○ モデルの更新をコードに正しく反映できているかわからなくなる ○モデルからコードを理解しにくくなる モデル コード
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77. ● 軽量DDD：DDDの実装パターンだけ取り入れること ● 拡張性の高いベストプラクティスを取り入れる →それだけでも十分価値がある ●コード品質をあげると、ようやくモデリングする余地が生まれる と考えることもできる 軽量DDDとは
- 78. ● 軽量DDD：DDDの実装パターンだけ取り入れること ● 拡張性の高いベストプラクティスを取り入れる →それだけでも十分価値がある ●コード品質をあげると、ようやくモデリングする余地が生まれる と考えることもできる ● 何の問題もない、 そこからモデリングに踏み出しましょう 軽量DDDとは
- 79.
- 80.
- 81.
- 82.
- 83. ドメインモデリングの方法 ● 一つに決まった方法はない ○ 体系化された手法の例 ■リレーションシップ駆動要件分析(RDRA) ■ ユースケース駆動分析設計 ● シンプルな例をご紹介 ユースケース図 / ドメインモデル図によるモデリング ● タスク管理アプリケーションにおける事例で説明する 83
- 84.
- 85.
- 86. ユースケース図 ● ユーザーとアプリケーションの相互作用を定義する ● 一般的なUMLのものと同じ ●次に続くドメイン図作成の範囲も決める 今回のモデリングのス コープ 86
- 87.
- 88. ● ユースケースの具体化・言語化 ○ 具体化しないと、どのようなモデルを作ればいいかわからない ○「いち作業者として、自分のタスクを管理したい」のか 「管理者として、複数作業者のタスク状況を管理したい」のか それによって「タスク」のドメインモデルは違うものになる ● ドメインモデル図作成作業の範囲を狭める ○ ユースケース図を作る必要性 88
- 89. ● ユースケースの具体化・言語化 ○ 具体化しないと、どのようなモデルを作ればいいかわからない ○「いち作業者として、自分のタスクを管理したい」のか 「管理者として、複数作業者のタスク状況を管理したい」のか それによって「タスク」のドメインモデルは違うものになる ● ドメインモデル図作成作業の範囲を狭める ○ ドメインモデル図作成をしていると、いろんな要素が思い浮かんでくる ○ 範囲を限定して、限られた時間でまとまった成果を出せるようにする ユースケース図を作る必要性 89
- 90. ドメインモデル図 ● クラス図の簡易版 ● メソッド(振る舞い)は不要 ●属性も代表的なものだけでOK ● 業務の「ルール・制約」(=ドメイン知識) を吹き出しで記述する ● 集約の範囲を明記する 90
- 91. 集約について ● 集約＝「必ず守りたい強い整合性を持ったオブジェクトのまとまり」 ● 必ずまとめて取得して、まとめて更新する単位 ●今回の発表では集約の検討が必要な事例は示せないが、 「このタイミングで集約設計する」ということを覚えておいてください 91
- 92.
- 93.
- 94.
- 95. まず、形から入る ● レイヤーを定義して「このレイヤにはこういうクラスを作る」というのを決める ● その決まりの上で、とりあえず動くものを書く ●参考：新卒にも伝わるドメイン駆動設計のアーキテクチャ説明 95
- 96.
- 97.
- 98.
- 99.
- 100.
- 101.
- 102.
- 103.
- 104.
- 105.
- 106. ● 修正前のクラスを再度確認 ● このクラスに、吹き出しの知識を委譲する Taskクラス-Before 106
- 107. Taskクラス -After (1/3)コンストラクタ ● コンストラクタにタスク作成時の知識を移譲 タスクは未完了状態で作成 される 107
- 108. Taskクラス -After (2/3)延期メソッド ● 延期メソッドに延期時の知識を移譲 タスクは3回だけ、 1日ずつ延期することができる。 108
- 109. Taskクラス -After (3/3)Setter ● Setterがなくなっているので、公開しているメソッド以外で操作できない 109
- 110.
- 111.
- 112.
- 113.
- 114.
- 115. ● お手本コードを作る ○ ApplicationService、Entity、Repository・・・ ●お手本に倣ってコードを書くようにチーム展開する ○ この段階では軽量DDDでも全然OK ● 「あれ、ドメイン層には何を書くべきなんだっけ？」 となったら、ドメインモデリングしてみる ● ドメインモデル図を元にリファクタリングしていく DDD導入の進め方 115
- 116.
- 117.
- 118. なぜお手本コード展開から入るのか ● 「原理を理解して実践」より、 「お手本を元に展開」の方が圧倒的に難易度が低いため ● ドメイン層に何を書くべきか？という疑問を持った方が モデリングの必要性を感じやすいため ●「どういうコードに落としこまれるのか」が イメージできてからの方が、ドメインモデリングしやすいため 118
- 119.
- 120.
- 121. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ●両方交互に経験値をためながら上達していくしかない コーディング モデリング 121
- 122. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ●両方交互に経験値をためながら上達していくしかない ● 結局、このサイクルのどちらから入るか、という違いだけ コーディング モデリング 122
- 123. 上達のイメージ ● DDDのコーディング、モデリング共に1発では上手くできない ● コーディングだけ、モデリングだけ上手くなるということもない ●両方交互に経験値をためながら上達していくしかない ● 結局、このサイクルのどちらから入るか、という違いだけ ● コーディングと、モデリングを意識的に両方少しずつやってみるのが良い コーディング モデリング 123
- 124. まとめ ● DDDでは、「モデルを継続的に改善」「モデルの更新をソフトウェアに反映」のアプロー チでソフトウェアの価値を高める ● モデルの更新を反映しやすいように、モデルをそのまま表現する その際にオブジェクト指向の手法を利用する ●DDD戦術設計パターンは、保守性の高い設計のベストプラクティス ● 設計パターンの適用(軽量DDD)と、モデリングを両方使うと、 ソフトウェアの価値を高められる ● 実装と、モデリングを少しずつ着手してみよう 124
- 125.
- 126. 宣伝になっちゃいますが。。 「ドメイン駆動設計 モデリング/実装ガイド」 (2020.3.1 技術書典8オンライン版発売予定) ・本日の内容は1,2章の内容 ・全部で11章仕立てです、興味お持ちいただけたら お買い求めくださいm(_ _)m ・boothで予約受付中 126
- 127. 質問箱で質問募集しています ● 質問いただければ回答します ● https://peing.net/ja/little_hands ●「質問箱 little_hands」で検索 127
- 128.
- 129.
- 130.