第一回 DDD 勉強会2016/04/14株式会社 FiNC 重村 裕紀 (Ruby エンジニア )
1. はじめに2.DDD とは何か3.DDD の目的4. 戦略的 DDD
5. 戦術的 DDD
0. 目次
1. はじめに
背景
1. はじめに
「 DDD 勉強会 企業」とかで出てきた会社
1. はじめに
Ruby の構文は表現機能が非常に高く、この言語の基礎水準は DDD にとって最適です。 Rails では、遂に、 1990 年代前半の Web 以前の UI作成技術と同じような簡単なウェブ UI の作成を実現しているということなので、私は非常に期待をもっています。Ruby の使用によってこの方向に進んでいけば、 ( おそらく、若干のインフラストラクチャ部品による補強は必要ですが )DDD を実現する理想的なプラットフォームも提供されるようになると考えています。
エリック・エヴァンス曰く…DDD と Ruby は相性良いらしい。
1. はじめに
DDD の概念をわかりやすく伝えます。
2. DDD とは何か ?
2. DDD とは何か ?
2. DDD とは?2-1. 概要
+ ドメイン駆動設計 (Domain Driven Design)
+ ドメインモデルを中心に考える設計思想+ ドメインとは、組織が行う事業やそれを取り巻く世界のこと。+ ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。 -> OOP のモデルと理解して OK
2. DDD とは?2-2. 具体例(コンビニ)
2. DDD とは?2-2. 具体例(コンビニ)
コンビニのレジシステムを表現して下さい。 2min
2. DDD とは?2-2. 具体例(コンビニ)
DDD ではモデルを用いて表現する。
2. DDD とは?2-2. 具体例(コンビニ)登場モデル顧客、レジ、商品1. 顧客モデル属性:お金振舞:購入する2. レジモデル属性:お金、購入履歴振舞:購入履歴を登録する。レシートを吐き出す。3. 商品モデル属性:お金、名前振舞:なし
2. DDD とは?2-1. 概要
2. DDD とは?2-2. 具体例(コンビニ)
お金モデル、レシートモデル、購入履歴モデル等が足りない。-> ドメインへの理解の深化
2. DDD とは?2-2. 具体例(コンビニ)
2. DDD とは?2-2. 具体例(コンビニ)
ドメインを考えるときに、これらのモデルを使ってドメインエキスパートとコミュニケーションをする。ドメインモデルは、 ( ユビキタスな ) 言語である。
DDD は言葉を大切にする設計思想。
2. DDD とは?2-3. 問題
DDD はなんの略?
2. DDD とは?2-3. 問題
ドメイン駆動設計(Domain Driven Design)
2. DDD とは?2-3. 問題
ドメインとは?
2. DDD とは?2-3. 問題
組織が行う事業やそれを取り巻く世界のこと。
2. DDD とは?2-3. 問題
ドメインモデルとは?
2. DDD とは?2-3. 問題
ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。
2. DDD とは?2-3. 問題
DDD とは?
2. DDD とは?2-1. 概要
ドメインモデルを中心に考える設計思想
2. DDD とは?2-4. まとめ
+ ドメイン駆動設計 (Domain Driven Design)
+ ドメインモデルを中心に考える設計思想+ ドメインとは、組織が行う事業やそれを取り巻く世界のこと。+ ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。+ ドメインモデルは言語+ DDD は言葉を大切にする設計思想
3.DDD の目的
3. DDD の目的
3.DDD の目的3-1. 結論
ソフトウェアの核心にある複雑性と闘うこと。
3.DDD の目的3-2. 歴史
ソフトウェアの歴史
3.DDD の目的3-2. 歴史
1960 年代末ソフトウェア危機
3.DDD の目的3-2. 歴史
ソフトウェア危機(ソフトウェアきき、 Software Crisis )とは、ソフトウェア工学がまだ十分に確立していなかった頃、よく使われた言葉である [1] 。この言葉は、コンピュータの急激な高性能化によってコンピュータ上のシステムが扱う問題が益々複雑化することによる影響を表したものである。
3.DDD の目的3-2. 歴史
-> ソフトウェア工学の誕生
3.DDD の目的3-2. 歴史
1970 年代構造化の時代(if 文や for 文使えみたいな?モジュール作れみたいな? )
3.DDD の目的3-2. 歴史
1980 年代沈滞期(管理技術へのシフト )
3.DDD の目的3-2. 歴史
1990 年代オブジェクト指向時代(Java: 1990 年代前半、 Python: 1991年、 Ruby: 1995 年 )
3.DDD の目的3-2. 歴史
1990 年代ソフトウェアプロセス( Extrem Programming/ アジャイル開発プロセス)
3.DDD の目的3-2. 歴史
2000 年代静的解析技術(UML)
3.DDD の目的3-2. 歴史
2003 年エリック・エバンスのドメイン駆動設計
3.DDD の目的3-2. 歴史
DDD は、オブジェクト指向やエクストリームプログラミングなどを体系化したもの。
3.DDD の目的3-3. 問題
DDD の目的は?
3.DDD の目的3-4. まとめ
+ DDD の目的は、ソフトウェアの核心にある複雑性と闘うこと。+ OOP や XP 等といったソフトウェア工学を体系化したもの。+ つまり、アジャイルでオブジェクト指向の恩恵を最大限受けるアプリケーションの考え方。
休憩 5min
4. 戦略的 DDD
4. 戦略的 DDD
5-1. 概要5. 戦術的 DDD
DDDの思想1 ドメインモデルを中心とした世界
戦略的DDD2 どうやってモデリングするか?
戦術的DDD3 どうやってモデルを実現するか?
4-1. はじめに4. 戦略的 DDD
抽象的で new ワードが出てきます。。
4-1. はじめに4. 戦略的 DDD
一番とっつきづらい。
4-1. はじめに4. 戦略的 DDD
しかし、一番大切
4-1. はじめに4. 戦略的 DDD
ドメイン中心の世界↓戦略的 DDD
(どうやってドメインをモデルで表すか? )↓戦術的 DDD
(どうやって実装するのか? )
4-1. はじめに4. 戦略的 DDD
覚えてもらいたい言葉1. ドメインエキスパート2. ユビキタス言語3. 境界づけられたコンテキスト4. コンテキストマップ
4-1. はじめに4. 戦略的 DDD
後で聞きます!
4-1. はじめに4. 戦略的 DDD
覚えてもらいたい言葉1. ドメインエキスパート2. ユビキタス言語3. 境界づけられたコンテキスト4. コンテキストマップ
4-2. ドメインエキスパート
+ そのドメインにおける業務知識を最も持つ人+ ソフトウェア開発者の仕事は、ドメインエキスパートのメンタルモデルアプリケーション上で実現することが仕事+ ※ メンタルモデルとは、人間が実世界で何かがどのように作用するかを思考する際のプロセスを表現したもの
4. 戦略的 DDD
食事指導のドメインエキスパート 人事のドメインエキスパート
4-3. ユビキタス言語4. 戦略的 DDD
覚えてもらいたい言葉1. ドメインエキスパート2. ユビキタス言語3. 境界づけられたコンテキスト4. コンテキストマップ
4-3. ユビキタス言語+ ドメインエキスパートやソフトウェア開発者を含めたチーム全体でつくり上げる言語のこと。+ ユビキタス言語が注目するのは、その業務自体が、どのような考えのもとでどのように動くのか。
4. 戦略的 DDD
StartUpMessage とは?InternalPayment とは?
CorporateSurveyDetail とは?CompanyAnalysisTrait とは?
専門的な例 抽象的な例User とは?
Manager とは?ProtoType とは?
Plan とは?
ユビキタス言語が構築されていれば問題ない
4-3. ユビキタス言語
ドメインエキスパートやソフトウェア開発者を含めたチーム全体でつくり上げる共有言語。
4. 戦略的 DDD
ユビキタス言語
ドメインエキスパートソフトウェア開発者
デザインパターン
技術用語
開発者が理解していないビジネス用語
設計には出てこないが誰もが使用するビジネス用語
4-3. ユビキタス言語4. 戦略的 DDD
この状況をコードで記述して下さい。 1min
4-3. ユビキタス言語4. 戦略的 DDD
「どうでもいいから、さっさとコード書こうよ。」
4-3. ユビキタス言語4. 戦略的 DDD
「インフルエンザの注射を患者に打つ。」
4-3. ユビキタス言語4. 戦略的 DDD
「ナースが患者に、インフルエンザワクチンを投与する。」
4-3. ユビキタス言語4. 戦略的 DDD
◯他社事例 (どこか忘れました )
ドメインエキスパートに、モデルのインターフェース ( 属性と public なメソッド ) をコードレビューしてもらうらしい。
4-4. 境界づけられたコンテキスト4. 戦略的 DDD
覚えてもらいたい言葉1. ドメインエキスパート2. ユビキタス言語3. 境界づけられたコンテキスト4. コンテキストマップ
4-4. 境界づけられたコンテキスト
ユビキタス言語が使われるコンテキストを明示したもの。境界を明示することで、ユビキタス言語の意味を定義する。
4. 戦略的 DDD
4-4. 境界づけられたコンテキスト4. 戦略的 DDD
銀行取引コンテキスト
アカウント (講座 ) とは、負債や信用取引の記録を保持するもの。ある顧客について、そ
の銀行における現在の財務状況を示す。
文学コンテキスト
アカウント (報告書 ) とは、ある期間における、関連する出来事についての文章を集めた
もの。
4-4. 境界づけられたコンテキスト4. 戦略的 DDD
境界づけられたコンテキスト
4-5. コンテキストマップ4. 戦略的 DDD
覚えてもらいたい言葉1. ドメインエキスパート2. ユビキタス言語3. 境界づけられたコンテキスト4. コンテキストマップ
4-5. コンテキストマップ
ドメインの世界地図
4. 戦略的 DDD
4-5-1. コンテキストマップの作り方
1. ドメインエキスパートを横に用意する2. サービスが解決したいドメインを定義3. ドメインを機能のまとまりに沿ってサブドメインに分割する4. サブドメインの集合をユビキタス言語の境界で切り分ける5. 境界づけられたコンテキスト間の上流と下流の関係を書く6. サブドメイン内で登場するドメインモデルを定義する
4. 戦略的 DDD
4-5. コンテキストマップ
人事評価システム
4. 戦略的 DDD
4-5-1-1. ドメインエキスパートを横に用意する。4. 戦略的 DDD
人事評価のドメインエキスパート
人事評価システムを作りたいんだよね〜
4-5-1-2. サービスが解決したいドメインを定義4. 戦略的 DDD
勤怠
給料売上成績
他社評価
役職プロフィール
勤怠や売上、他社からの評価等を元に、給料や、役職を決定するシステムを作りたい。人事評価ドメイン
4-5-1-2. サービスが解決したいドメインを定義4. 戦略的 DDD
勤怠や売上、他社からの評価等を元に、給料や、役職を決定するシステム
人事評価ドメイン
4-5-1-3. ドメインを機能のまとまりに沿ってサブドメインに分割する4. 戦略的 DDD
人事評価ドメイン
従業員アカウント管理サブドメイン
集計サブドメイン 評価サブドメイン
4-5-1-4. サブドメインの集合をユビキタス言語の境界で切り分ける4. 戦略的 DDD
人事評価ドメイン
従業員アカウント管理サブドメイン
集計サブドメイン 評価サブドメイン
評価コンテキスト
管理コンテキスト
4-5-1-4. サブドメインの集合をユビキタス言語の境界で切り分ける4. 戦略的 DDD
人事評価ドメイン
従業員アカウント管理サブドメイン
集計サブドメイン 評価サブドメイン
評価コンテキスト
管理コンテキスト
あくまでユビキタス言語の境界
4-5-1-5. 境界づけられたコンテキスト間の上流と下流の関係を書く4. 戦略的 DDD
人事評価ドメイン
従業員アカウント管理サブドメイン
集計サブドメイン 評価サブドメイン
評価コンテキスト
管理コンテキスト
U
U U
D
D D
4-5-1-6. サブドメイン内で登場するドメインモデルを定義する4. 戦略的 DDD
集計サブドメイン
Attendance勤怠Employee従業員
OtherCompaniesEvaluation他社評価CultureFit文化共感度
ImprovementOriented改善志向EvaluationService評価サービス
4-5-1. コンテキストマップの作り方
1. ドメインエキスパートを横に用意する2. サービスが解決したいドメインを定義3. ドメインを機能のまとまりに沿ってサブドメインに分割する4. サブドメインの集合をユビキタス言語の境界で切り分ける5. 境界づけられたコンテキスト間の上流と下流の関係を書く6. サブドメイン内で登場するドメインモデルを定義する
4. 戦略的 DDD
4-5-3. コンテキストマップまとめ4. 戦略的 DDD
ドメインエキスパートとモデルを通じて会話し、ユビキタス言語を構築すること。
4-6. 問題4. 戦略的 DDD
ドメインエキスパートとは?
4-6. 問題4. 戦略的 DDD
そのドメインにおける業務知識を最も持つ人
4-6. 問題4. 戦略的 DDD
ユビキタス言語とは?
4-6. 問題4. 戦略的 DDD
ドメインエキスパートやソフトウェア開発者を含めたチーム全体でつくり上げる共有言語。
4-6. 問題4. 戦略的 DDD
境界づけられたコンテキストとは?
4-6. 問題4. 戦略的 DDD
ユビキタス言語が使われるコンテキストを明示したもの。
4-6. 問題4. 戦略的 DDD
コンテキストマップとは?
4-6. 問題4. 戦略的 DDD
ドメインの世界地図
4-.7 まとめ
ドメインエキスパートそのドメインにおける業務知識を最も持つ人ユビキタス言語ドメインエキスパートやソフトウェア開発者を含めたチーム全体でつくり上げる言語のこと。境界づけられたコンテキストユビキタス言語が使われるコンテキストを明示したもの。コンテキストマップドメインの世界地図
4. 戦略的 DDD
休憩 5min
5. 戦術的 DDD
5. 戦術的 DDD
5-1. 概要5. 戦術的 DDD
DDDの思想1 ドメインモデルを中心とした世界
戦略的DDD2 どうやってモデリングするか?
戦術的DDD3 どうやってモデルを実現するか?
5-1. 概要
ドメインモデル中心の世界をアプリケーション上で実現するための戦術。パターン・ランゲージや、アーキテクチャの話はここから出てくる。10 年たった今でもどうやって実装するか議論が重ねられている。
5. 戦術的 DDD
5-1. 概要5. 戦術的 DDD
ドメインをアプリケーションの都合から隔離すること。ドメインをモデルを用いて豊かに表現すること。
ドメインを隔離するためのアーキテクチャ:レイヤードアーキテクチャ
ドメインを表現するパターン・ランゲージ: Entity, Servic …
5-2. レイヤードアーキテクチャ
アプリケーションの責務をレイヤーに分割上位のレイヤーは下位のレイヤーに依存する下位のレイヤーは上位のレイヤーに依存してはならない
5. 戦術的 DDD
5-2. レイヤードアーキテクチャ 5. 戦術的 DDD
• アプリケーションの責務をレイヤーに分割• 上位のレイヤーは下位のレイヤーに依存する• 下位のレイヤーは上位のレイヤーに依存してはならない
5-2. レイヤードアーキテクチャ
+ ユーザーに情報を表示して、ユーザーのコマンドを解釈する責務を負う。外部アクタは人間のユーザーではなく、別のコンピューターシステムのこともある。+ 例 ) View, API
5. 戦術的 DDD
5-2. レイヤードアーキテクチャ
+ ユースケース ( シナリオ ) を定義し、ドメインオブジェクトが問題を解決するように導く。ビジネスルールや知識を含まず、やるべき作業を調整するだけ。実際の処理は下位のレイヤーに以上する。+ 例: Controller, Rake, API の実装 , ApplicationService
5. 戦術的 DDD
5-2. レイヤードアーキテクチャ
コントローラーとアプリケーションサービスの責務の違い# コントローラー+ HTTP リクエストを受信して然るべきアプリケーションサービスに渡す。+ アプリケーションサービスから、 HTTP レスポンスを返す。# アプリケーションサービス+ ユースケースを定義する+ ドメインオブジェクトが問題を解決するように調整する。
5. 戦術的 DDD
5-2. レイヤードアーキテクチャ 5. 戦術的 DDD
5-2. レイヤードアーキテクチャ
+ ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの+ ユビキタス言語で作られるべきである。+ Entity, Service, ValueObject, Factory, Repository 等がいる。+ ソフトウェアの核心である。+ UI層にドメインが漏れだすことは許されない。
5. 戦術的 DDD
5-2. レイヤードアーキテクチャ
+ 上位のレイヤーを支える技術的機能を提供する。+ 例: HTTP 、 MySQL 、外部 API 、 ActiveRecord 、 Rails 等
5. 戦術的 DDD
5-2. レイヤードアーキテクチャ 5. 戦術的 DDD
ドメイン層とインフラ層を分けることで DB リファクタ (正規化、キャッシュテーブル、マイクロサービス ) をしても、ビジネスロジックが変わらなければドメイン層には影響がない。
5-3. 問題
レイヤードアーキテクチャの構成は?
5. 戦術的 DDD
5. 戦術的 DDD
5-3. 問題
レイヤードアーキテクチャのルールは?
5. 戦術的 DDD
5-3. 問題
アプリケーションの責務をレイヤーに分割上位のレイヤーは下位のレイヤーに依存する下位のレイヤーは上位のレイヤーに依存してはならない
5. 戦術的 DDD
5-3. 問題
UI層の責務は?
5. 戦術的 DDD
5-3. 問題
ユーザーに情報を表示して、ユーザーのコマンドを解釈する責務を負う。外部アクタは人間のユーザーではなく、別のコンピューターシステムのこともある。
5. 戦術的 DDD
5-3. 問題
Application層の責務は?
5. 戦術的 DDD
5-3. 問題
ユースケース ( シナリオ ) を定義し、ドメインオブジェクトが問題を解決するように導く。ビジネスルールや知識を含まず、やるべき作業を調整するだけ。実際の処理は下位のレイヤーに以上する。
5. 戦術的 DDD
5-3. 問題
Domain層の責務は?
5. 戦術的 DDD
5-3. 問題
ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの
5. 戦術的 DDD
5-3. 問題
Infrastructure層の責務は?
5. 戦術的 DDD
5-3. 問題
上位のレイヤーを支える技術的機能を提供する。
5. 戦術的 DDD
5-3. 問題
なぜ Infrastructure層とDomain層を分けるべきか?
5. 戦術的 DDD
5-3. 問題
上位のレイヤーを支える技術的機能を提供する。
5. 戦術的 DDD
5-3. 問題
ビジネスロジックと、技術的な関心事を疎結合にすることでドメインを中心とした世界を作る。
5. 戦術的 DDD
5-3. 問題
休憩 5min
ドメインモデルを豊かに表現する。
5. 戦術的 DDD
5-4. パターン・ランゲージ
ドメインモデルを豊かに表現する。
5. 戦術的 DDD
5-4. パターン・ランゲージ
5. 戦術的 DDD
Entity オブジェクトのライフサイクルにおいて一意性を保つ必要があるオブジェクトValueObject一意性を持たないオブジェクトRepositoryオブジェクトの永続化のインターフェースを提供するAggregate集約Factory複雑なオブジェクトを組み立てる。Serviceオブジェクトの振舞には収まらない操作。
5-4. パターン・ランゲージ
同一性を保持する必要のあるドメインオブジェクト属性が変わっても、同一性が必要。属性が同じでも、区別したいオブジェクト例: User, Product, Company
5. 戦術的 DDD
5-4. Entity
5. 戦術的 DDD
5-4. Entity
属性が変わっても同一性を保ちたい。
5. 戦術的 DDD
Entity オブジェクトのライフサイクルにおいて一意性を保つ必要があるオブジェクトValueObject一意性を持たないオブジェクトRepositoryライフサイクルの中長期的な保存の責務をおうAggregate集約Factory複雑なオブジェクトを組み立てる。Serviceオブジェクトの振舞には収まらない操作。
5-4. パターン・ランゲージ
Entity とは逆に、例えば「色」や「量」のように、属性だけが重要で、アイデンティティを考えるひつようのないオブジェクト属性が同じならば、同じと考える。例: Red, Email, Age, Money
5. 戦術的 DDD
5-4. ValueObject
5. 戦術的 DDD
5-5. ValueObject
属性が同じならば、同じ
5. 戦術的 DDD
Entity オブジェクトのライフサイクルにおいて一意性を保つ必要があるオブジェクトValueObject一意性を持たないオブジェクトRepositoryオブジェクトの永続化のインターフェースを提供するAggregate集約Factory複雑なオブジェクトを組み立てる。Serviceオブジェクトの振舞には収まらない操作。
5-4. パターン・ランゲージ
5. 戦術的 DDD
5-6. Repository
いわゆるリポジトリババアそれだけ重要。ライフサイクルの中長期的な保存の責務を負う。SQL発行等は Infra層インターフェースだけ提供
5. 戦術的 DDD
5-6. Repository
ただ、冷凍するだけ。ただ、解答するだけ。Validation はドメインオブジェクト自身が持つ。
5. 戦術的 DDD
5-7. Aggregate
いわゆる集約。モチベーションは、関連を最小限に抑えること。-> 関係性の爆発的増加もある程度制限される。-> 関係性の境界を引くことが大切。-> 集約
5. 戦術的 DDD
5-7. Aggregate
・集約のルートエンティティは、グローバルな同一性を持つ。・集約の境界外から境界内部のオブジェクトにアクセスしてはいけない。・境界内部には集約ルートのみアクセスできる。
自動車集約ルート
シート
エンジン
タイヤ
集約ルートを介さずアクセスしてはいけない。アクセスできる。
5. 戦術的 DDD
5-8. Factory
複雑なオブジェクトをただ組み立てるだけ。Repository は、ただ冷凍と解凍のインターフェースのみ提供。Factory はオブジェクトを組み立てるだけ。Repository の内部で呼び出されることもある。
5. 戦術的 DDD
5-8. Factory
永続化とは関係ない。ただ複雑なオブジェクトを組み立てるだけ。まあ、あんまり使わない。
5. 戦術的 DDD
5-9. Service
時には単純に「物」に出来上に事もある。概念的にオブジェクトに属さない操作をサービスと呼ぶ。サービスは、関数 (状態を持たない。 )
例: ScoringService, ShuffleService
5. 戦術的 DDD
5-9. Service
Ruby ならばインスタンス化しても良いが、基本的には状態を持たない関数まずは、ドメインオブジェクトの振舞にもたせられないか考えるべし。
5. 戦術的 DDD
5-10. 問題
2. DDD とは何か ?
2. DDD とは何か ?
2. DDD とは?2-1. 概要
+ ドメイン駆動設計 (Domain Driven Design)
+ ドメインモデルを中心に考える設計思想+ ドメインとは、組織が行う事業やそれを取り巻く世界のこと。+ ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。 -> OOP のモデルと理解して OK
2. DDD とは何か ?
第二回実践ドメイン駆動設計Rails × MicroService
× DDD2016 年 5月中
2. DDD とは何か ?
ありがとうございました。
Top Related