Slide 1

Slide 1 text

ドメイン駆動設計のはなし キッチハイク社内勉強会 2021/9/1 小川 剛

Slide 2

Slide 2 text

● ドメイン駆動設計ってなに? ● DDD on Rails ● 私たちにできること 本日はなすこと

Slide 3

Slide 3 text

ドメイン駆動設計ってなに?

Slide 4

Slide 4 text

● エリック・エヴァンス「ドメイン駆動設 計」(原著:2003)にて提唱された設計 手法に端を発する ● ドメインに焦点をあてた設計手法 ドメイン駆動設計(DDD)とは

Slide 5

Slide 5 text

● ドメイン ○ 知識、影響力、または活動の領域。ユーザーがプログラムを適用する対象領 域がソフトウェアのドメインとなる ● モデル(ドメインモデル) ○ あるドメインについて、そのうちの選択された側面を記述し、そのドメインに関 連する問題を解決するために使うことのできる、抽象化されたシステム。 ( https://zenn.dev/takahashim/books/fb4cdc32f8e95c より引用 ) DDDのキー概念: ドメインとモデル

Slide 6

Slide 6 text

● ソフトウェア化の対象となるドメインの知識を深める ● ドメインの知識を整理して、ドメインモデルに反映する ● ドメインモデルをソフトウェアに反映する ● これらを継続的に行っていくことでソフトウェアを設計・開発する手法であ る 改めてDDDとは

Slide 7

Slide 7 text

https://www.nri.com/-/media/Corporate/jp/Files/PDF/knowledge/publication/chitekishisan/2020/09/cs20200910.pdf を参考 DDDのサイクル ドメイン知識 ドメインモデル ソフトウェア ドメインエキスパート 開発者 ユビキタス言語

Slide 8

Slide 8 text

● ドメインエキスパート ○ そのソフトウェアのドメインに対して、知識を持っている人 ○ 例: 会計処理のドメインは会計担当の人が一番詳しい ● ユビキタス言語 ○ ドメインモデルを中心に構造化された言語 ○ メンバーはユビキタス言語を統一してあらゆる場所で使うようにする DDDのサイクル

Slide 9

Slide 9 text

● 開発者とドメインエキスパートが対話しながら、ドメイン知識をドメインモデ ルに反映させ、成長させていく。 ● このドメインモデルをソフトウェアとして実装していく ● ドメインモデルは関係者のドメイン知識が深まったり、またドメインが改善 されていく中で、生き物のように変化していく ● したがって、ドメインモデルを更新し続けていく継続的なプロセスである DDDのサイクル

Slide 10

Slide 10 text

● 開発者とドメインエキスパートが対話しながら業務知識を深めていくこと で、より高いレベルでソフトウェアにドメイン知識を反映していくことができ る ● ソフトウェアのドメイン知識が高凝集・疎結合であることで継続的なメンテ ナンス性が高まる DDDでどんないいことがあるの?

Slide 11

Slide 11 text

https://www.domainlanguage.com/wp-content/uploads/2016/04/Pattern-Language-Overview-med.png

Slide 12

Slide 12 text

DDDのアーキテクチャ要素 ● たくさんある・・・ ○ レイヤ化アーキテクチャ ○ 値オブジェクト ○ リポジトリ ○ エンティティ ○ 集約 ○ サービス等々 ● これらの詳細な説明は今回のスコープではないので、後の説明で出てくるもの だけご紹介します

Slide 13

Slide 13 text

● アプリケーションを以下4つの層に分割する ○ プレゼンテーション層 ○ アプリケーション層 ○ ドメイン層 ○ インフラストラクチャ層 ● ドメイン層は、データアクセスのための技術的機 能(インフラストラクチャ)や、ユースケースの実行 (アプリケーション層)とは別の層に隔離されてい る レイヤ化アーキテクチャ https://ajlopez.wordpress.com/2008/09/12/layered-architecture-in-domain-driven-design/

Slide 14

Slide 14 text

リポジトリ 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の場合、モデル は永続化層(データベースの テーブル)をそのままラップした ものになる

Slide 15

Slide 15 text

● DDDで提唱されているアーキテクチャは、総じてドメイン層 / ドメインモデ ルをドメインロジックのみに純化するのが目的である(と思う) ● ドメイン層がドメインロジックの表現のみに専念できるようにするため、責 務の異なるものは分離する ● 責務の異なるものは別のドメインモデル、あるいは層に分けていく DDDのアーキテクチャの目的

Slide 16

Slide 16 text

DDD on Rails

Slide 17

Slide 17 text

Ruby on RailsはDDDには 不向きと言われるけどどうなの

Slide 18

Slide 18 text

● 静的型付け言語のほうがドメインモデルのルールを型を通じて表現しやす いと言われている ● 一方でRubyの表現力は、ドメインをコードに分かりやすく落とし込むことが 可能である。DSLが良い例。 ● やりやすいところもあるし、やりにくいところもあるんじゃないかなという感 想 RubyとDDD

Slide 19

Slide 19 text

● Active Recordの制約 ○ Active Recordはテーブル = エンティ ティを前提としている ○ データベースの構造がドメインの構造と 密結合してしまう ○ Repositoryを介したデータアクセスがし づらい DDD on Rails https://bliki-ja.github.io/pofeaa/ActiveRecord/

Slide 20

Slide 20 text

● もちろんRails自体はAR以外のORマッパーを使えるようになっている ● だが、現状AR一強になっているために、それ以外の強力な選択肢が少な い ● Active Recordを使うのであれば、ActiveRecordのモデルをインフラス トラクチャ層内に制限して、ドメイン層にモデルクラスを持たせるなどの工 夫が必要になる DDD on Rails

Slide 21

Slide 21 text

● Hanami ○ Clean Architectureベースのアーキテクチャ設計 ● ROM(Ruby Object Mapper) ○ 上述のHanamiでも使用されているORM(公式はORMとは呼んでほ しくなさそう・・・) ○ Entity / Repositoryの分離が前提となっている Rails / Active Record以外の選択肢

Slide 22

Slide 22 text

こうした議論はすごく楽しいけど どこか違和感

Slide 23

Slide 23 text

言語やフレームワークが DDDに向いている向いてないの前に やれることがあるんじゃないか

Slide 24

Slide 24 text

私たちにできること

Slide 25

Slide 25 text

DDDのアーキテクチャは何のため? ● DDDのアーキテクチャに則っている = DDDができている、ではないはず ● アーキテクチャは、ソフトウェアのドメインモデルの実装を疎結合・高凝集 にしていくためのものである ● RailsではDDDのアーキテクチャが適用しにくい = DDDができない、のよ うな短絡化を避けたいという思いもある

Slide 26

Slide 26 text

ドメイン知識 ドメインモデル ソフトウェア ドメインエキスパート 開発者 ユビキタス言語 アーキテクチャは この領域の 一部分でしかない

Slide 27

Slide 27 text

● アーキテクチャをあれこれ話すのは楽しい・・・でもDDD全体において、そ れは一部分の要素でしかない ● よりよい設計・開発を目指すのであれば、もっと別の要素にも目を向けて いくべきではないのか ● ドメインエキスパートとどう対話していくか、ドメインをどうモデリングしてい くかに着目できないか ○ 以降では特にドメインモデリングについて触れる アーキテクチャ以外の領域へ

Slide 28

Slide 28 text

ドメイン知識 ドメインモデル ソフトウェア ドメインエキスパート 開発者 ユビキタス言語 私たちは こちらにもっと着目すべきではな いか?

Slide 29

Slide 29 text

ドメインモデリングに向き合えている? ● モデリングのプロセスを簡略化してしまっていないか ● 現在のモデルに継ぎ足し継ぎ足しで考えるのが当たり前になっていない か ● それらの積み重ねの結果として、モデルの無軌道な肥大化に繋がってい ないだろうか

Slide 30

Slide 30 text

よりよいドメインモデリングのために ● DDD本では、具体的にどうドメインモデリングをすればよいかは書いてい ない ● どのようにドメインモデリングをしていけばよいか?

Slide 31

Slide 31 text

ドメイン駆動設計 モデリング / 実践ガイド ● とっても良い本です・・・! ● この本では、ユースケース図 / ドメ インモデル図をもとに、実装に反映 させていくアプローチを取っている

Slide 32

Slide 32 text

「ドメイン駆動設計 モデリング / 実践ガイド」で のプロセス概要 ● モデルが解決する課題を具体化するため にユースケース図を起こす ● ドメインモデル図を起こして、集約の範囲 や関連などを可視化する ● ドメインモデルを実装する ● 実装の知見をもとにドメインモデルを改善 していく ドメインモデリングのプロセス

Slide 33

Slide 33 text

モデリングスキルのレベルアップ ● モデリングに対して先人がどう向き合ってきた か ● UMLモデリング、データモデリングのプロセス から学ぶ ○ 概念をいかにしてモデル化していくか ● 特定ユースケースにおいて定石となるモデリン グパターンから学ぶ ○ アナリシスパターン

Slide 34

Slide 34 text

● DDDとはドメインエキスパートとの対話を通じて、ドメインモデルを深化さ せ、継続的に反映していくプロセスである ● DDDについてはアーキテクチャについつい目が行きがちであるが、それら はソフトウェアのドメインをいかに疎結合・高凝集にしていくための手段で ある ● ドメインをどうモデリングしていくかの技法について、私たちはまだまだ学 ぶことがあるはず まとめ