キッチハイク社内勉強会 ドメイン駆動設計のはなし / 2021-09-01

Transcript

1. ドメイン駆動設計のはなし キッチハイク社内勉強会 2021/9/1 小川 剛
2. • ドメイン駆動設計ってなに？ • DDD on Rails • 私たちにできること 本日はなすこと
3. ドメイン駆動設計ってなに？
4. • エリック・エヴァンス「ドメイン駆動設 計」(原著:2003)にて提唱された設計 手法に端を発する • ドメインに焦点をあてた設計手法 ドメイン駆動設計(DDD)とは
5. • ドメイン ◦ 知識、影響力、または活動の領域。ユーザーがプログラムを適用する対象領 域がソフトウェアのドメインとなる • モデル(ドメインモデル) ◦ あるドメインについて、そのうちの選択された側面を記述し、そのドメインに関 連する問題を解決するために使うことのできる、抽象化されたシステム。 ( https://zenn.dev/takahashim/books/fb4cdc32f8e95c より引用 ) DDDのキー概念: ドメインとモデル
6. • ソフトウェア化の対象となるドメインの知識を深める • ドメインの知識を整理して、ドメインモデルに反映する • ドメインモデルをソフトウェアに反映する • これらを継続的に行っていくことでソフトウェアを設計・開発する手法であ る 改めてDDDとは
7. https://www.nri.com/-/media/Corporate/jp/Files/PDF/knowledge/publication/chitekishisan/2020/09/cs20200910.pdf を参考 DDDのサイクル ドメイン知識 ドメインモデル ソフトウェア ドメインエキスパート 開発者 ユビキタス言語
8. • ドメインエキスパート ◦ そのソフトウェアのドメインに対して、知識を持っている人 ◦ 例: 会計処理のドメインは会計担当の人が一番詳しい • ユビキタス言語 ◦ ドメインモデルを中心に構造化された言語 ◦ メンバーはユビキタス言語を統一してあらゆる場所で使うようにする DDDのサイクル
9. • 開発者とドメインエキスパートが対話しながら、ドメイン知識をドメインモデ ルに反映させ、成長させていく。 • このドメインモデルをソフトウェアとして実装していく • ドメインモデルは関係者のドメイン知識が深まったり、またドメインが改善 されていく中で、生き物のように変化していく • したがって、ドメインモデルを更新し続けていく継続的なプロセスである DDDのサイクル
10. • 開発者とドメインエキスパートが対話しながら業務知識を深めていくこと で、より高いレベルでソフトウェアにドメイン知識を反映していくことができ る • ソフトウェアのドメイン知識が高凝集・疎結合であることで継続的なメンテ ナンス性が高まる DDDでどんないいことがあるの？
11. https://www.domainlanguage.com/wp-content/uploads/2016/04/Pattern-Language-Overview-med.png
12. DDDのアーキテクチャ要素 • たくさんある・・・ ◦ レイヤ化アーキテクチャ ◦ 値オブジェクト ◦ リポジトリ ◦ エンティティ ◦ 集約 ◦ サービス等々 • これらの詳細な説明は今回のスコープではないので、後の説明で出てくるもの だけご紹介します
13. • アプリケーションを以下4つの層に分割する ◦ プレゼンテーション層 ◦ アプリケーション層 ◦ ドメイン層 ◦ インフラストラクチャ層 • ドメイン層は、データアクセスのための技術的機 能(インフラストラクチャ)や、ユースケースの実行 (アプリケーション層)とは別の層に隔離されてい る レイヤ化アーキテクチャ https://ajlopez.wordpress.com/2008/09/12/layered-architecture-in-domain-driven-design/
14. リポジトリ class User attr_reader :id, :name, :email def initialize(name, email) # ... end # ドメインロジック def signup # ... end end class UserRepository # 永続化層へのインターフェース def save(user) # ... end end # ドメインオブジェクトの永続化はリポジトリ経由で行う userRepository.save(user) • ドメインオブジェクトに対し、永続 化層(データベース等)へのアク セスを提供するもの • ドメインオブジェクトと永続化層 が疎結合になる • Active Recordの場合、モデル は永続化層(データベースの テーブル)をそのままラップした ものになる
15. • DDDで提唱されているアーキテクチャは、総じてドメイン層 / ドメインモデ ルをドメインロジックのみに純化するのが目的である(と思う) • ドメイン層がドメインロジックの表現のみに専念できるようにするため、責 務の異なるものは分離する • 責務の異なるものは別のドメインモデル、あるいは層に分けていく DDDのアーキテクチャの目的
16. DDD on Rails
17. Ruby on RailsはDDDには 不向きと言われるけどどうなの
18. • 静的型付け言語のほうがドメインモデルのルールを型を通じて表現しやす いと言われている • 一方でRubyの表現力は、ドメインをコードに分かりやすく落とし込むことが 可能である。DSLが良い例。 • やりやすいところもあるし、やりにくいところもあるんじゃないかなという感 想 RubyとDDD
19. • Active Recordの制約 ◦ Active Recordはテーブル = エンティ ティを前提としている ◦ データベースの構造がドメインの構造と 密結合してしまう ◦ Repositoryを介したデータアクセスがし づらい DDD on Rails https://bliki-ja.github.io/pofeaa/ActiveRecord/
20. • もちろんRails自体はAR以外のORマッパーを使えるようになっている • だが、現状AR一強になっているために、それ以外の強力な選択肢が少な い • Active Recordを使うのであれば、ActiveRecordのモデルをインフラス トラクチャ層内に制限して、ドメイン層にモデルクラスを持たせるなどの工 夫が必要になる DDD on Rails
21. • Hanami ◦ Clean Architectureベースのアーキテクチャ設計 • ROM(Ruby Object Mapper) ◦ 上述のHanamiでも使用されているORM(公式はORMとは呼んでほ しくなさそう・・・) ◦ Entity / Repositoryの分離が前提となっている Rails / Active Record以外の選択肢
22. こうした議論はすごく楽しいけど どこか違和感
23. 言語やフレームワークが DDDに向いている向いてないの前に やれることがあるんじゃないか
24. 私たちにできること
25. DDDのアーキテクチャは何のため？ • DDDのアーキテクチャに則っている = DDDができている、ではないはず • アーキテクチャは、ソフトウェアのドメインモデルの実装を疎結合・高凝集 にしていくためのものである • RailsではDDDのアーキテクチャが適用しにくい = DDDができない、のよ うな短絡化を避けたいという思いもある
26. ドメイン知識 ドメインモデル ソフトウェア ドメインエキスパート 開発者 ユビキタス言語 アーキテクチャは この領域の 一部分でしかない
27. • アーキテクチャをあれこれ話すのは楽しい・・・でもDDD全体において、そ れは一部分の要素でしかない • よりよい設計・開発を目指すのであれば、もっと別の要素にも目を向けて いくべきではないのか • ドメインエキスパートとどう対話していくか、ドメインをどうモデリングしてい くかに着目できないか ◦ 以降では特にドメインモデリングについて触れる アーキテクチャ以外の領域へ
28. ドメイン知識 ドメインモデル ソフトウェア ドメインエキスパート 開発者 ユビキタス言語 私たちは こちらにもっと着目すべきではな いか？
29. ドメインモデリングに向き合えている？ • モデリングのプロセスを簡略化してしまっていないか • 現在のモデルに継ぎ足し継ぎ足しで考えるのが当たり前になっていない か • それらの積み重ねの結果として、モデルの無軌道な肥大化に繋がってい ないだろうか
30. よりよいドメインモデリングのために • DDD本では、具体的にどうドメインモデリングをすればよいかは書いてい ない • どのようにドメインモデリングをしていけばよいか？
31. ドメイン駆動設計 モデリング / 実践ガイド • とっても良い本です・・・！ • この本では、ユースケース図 / ドメ インモデル図をもとに、実装に反映 させていくアプローチを取っている
32. 「ドメイン駆動設計 モデリング / 実践ガイド」で のプロセス概要 • モデルが解決する課題を具体化するため にユースケース図を起こす • ドメインモデル図を起こして、集約の範囲 や関連などを可視化する • ドメインモデルを実装する • 実装の知見をもとにドメインモデルを改善 していく ドメインモデリングのプロセス
33. モデリングスキルのレベルアップ • モデリングに対して先人がどう向き合ってきた か • UMLモデリング、データモデリングのプロセス から学ぶ ◦ 概念をいかにしてモデル化していくか • 特定ユースケースにおいて定石となるモデリン グパターンから学ぶ ◦ アナリシスパターン
34. • DDDとはドメインエキスパートとの対話を通じて、ドメインモデルを深化さ せ、継続的に反映していくプロセスである • DDDについてはアーキテクチャについつい目が行きがちであるが、それら はソフトウェアのドメインをいかに疎結合・高凝集にしていくための手段で ある • ドメインをどうモデリングしていくかの技法について、私たちはまだまだ学 ぶことがあるはず まとめ