finc ddd第一回勉強会

第一回 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-1. 概要

+ ドメイン駆動設計 (Domain Driven Design)

+ ドメインモデルを中心に考える設計思想+ ドメインとは、組織が行う事業やそれを取り巻く世界のこと。+ ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。 -> OOP のモデルと理解して OK

2. DDD とは？2-2. 具体例（コンビニ）


コンビニのレジシステムを表現して下さい。 2min


DDD ではモデルを用いて表現する。

2. DDD とは？2-2. 具体例（コンビニ）登場モデル顧客、レジ、商品1. 顧客モデル属性：お金振舞：購入する2. レジモデル属性：お金、購入履歴振舞：購入履歴を登録する。レシートを吐き出す。3. 商品モデル属性：お金、名前振舞：なし


お金モデル、レシートモデル、購入履歴モデル等が足りない。-> ドメインへの理解の深化


ドメインを考えるときに、これらのモデルを使ってドメインエキスパートとコミュニケーションをする。ドメインモデルは、 ( ユビキタスな ) 言語である。

DDD は言葉を大切にする設計思想。

2. DDD とは？2-3. 問題

DDD はなんの略？


ドメイン駆動設計(Domain Driven Design)


ドメインとは？


組織が行う事業やそれを取り巻く世界のこと。


ドメインモデルとは？


ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。


DDD とは？


ドメインモデルを中心に考える設計思想

2. DDD とは？2-4. まとめ


+ ドメインモデルを中心に考える設計思想+ ドメインとは、組織が行う事業やそれを取り巻く世界のこと。+ ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。+ ドメインモデルは言語+ DDD は言葉を大切にする設計思想

3.DDD の目的

3. DDD の目的

3.DDD の目的3-1. 結論

ソフトウェアの核心にある複雑性と闘うこと。

3.DDD の目的3-2. 歴史

ソフトウェアの歴史


1960 年代末ソフトウェア危機


ソフトウェア危機（ソフトウェアきき、 Software Crisis ）とは、ソフトウェア工学がまだ十分に確立していなかった頃、よく使われた言葉である [1] 。この言葉は、コンピュータの急激な高性能化によってコンピュータ上のシステムが扱う問題が益々複雑化することによる影響を表したものである。


-> ソフトウェア工学の誕生


1970 年代構造化の時代(if 文や for 文使えみたいな？モジュール作れみたいな？ )


1980 年代沈滞期(管理技術へのシフト )


1990 年代オブジェクト指向時代(Java: 1990 年代前半、 Python: 1991年、 Ruby: 1995 年 )


1990 年代ソフトウェアプロセス（ Extrem Programming/ アジャイル開発プロセス）


2000 年代静的解析技術(UML)


2003 年エリック・エバンスのドメイン駆動設計


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 ワードが出てきます。。


一番とっつきづらい。


しかし、一番大切


ドメイン中心の世界↓戦略的 DDD

(どうやってドメインをモデルで表すか？ )↓戦術的 DDD

(どうやって実装するのか？ )


覚えてもらいたい言葉1. ドメインエキスパート2. ユビキタス言語3. 境界づけられたコンテキスト4. コンテキストマップ


後で聞きます！

4-2. ドメインエキスパート

+ そのドメインにおける業務知識を最も持つ人+ ソフトウェア開発者の仕事は、ドメインエキスパートのメンタルモデルアプリケーション上で実現することが仕事+ ※ メンタルモデルとは、人間が実世界で何かがどのように作用するかを思考する際のプロセスを表現したもの

4. 戦略的 DDD

食事指導のドメインエキスパート人事のドメインエキスパート

4-3. ユビキタス言語4. 戦略的 DDD


4-3. ユビキタス言語+ ドメインエキスパートやソフトウェア開発者を含めたチーム全体でつくり上げる言語のこと。+ ユビキタス言語が注目するのは、その業務自体が、どのような考えのもとでどのように動くのか。

4. 戦略的 DDD

StartUpMessage とは？InternalPayment とは？

CorporateSurveyDetail とは？CompanyAnalysisTrait とは？

専門的な例抽象的な例User とは？

Manager とは？ProtoType とは？

Plan とは？

ユビキタス言語が構築されていれば問題ない

4-3. ユビキタス言語

ドメインエキスパートやソフトウェア開発者を含めたチーム全体でつくり上げる共有言語。

4. 戦略的 DDD

ユビキタス言語

ドメインエキスパートソフトウェア開発者

デザインパターン

技術用語

開発者が理解していないビジネス用語

設計には出てこないが誰もが使用するビジネス用語


この状況をコードで記述して下さい。 1min


「どうでもいいから、さっさとコード書こうよ。」


「インフルエンザの注射を患者に打つ。」


「ナースが患者に、インフルエンザワクチンを投与する。」


◯他社事例 (どこか忘れました )

ドメインエキスパートに、モデルのインターフェース ( 属性と public なメソッド ) をコードレビューしてもらうらしい。

4-4. 境界づけられたコンテキスト4. 戦略的 DDD


4-4. 境界づけられたコンテキスト

ユビキタス言語が使われるコンテキストを明示したもの。境界を明示することで、ユビキタス言語の意味を定義する。

4. 戦略的 DDD


銀行取引コンテキスト

アカウント (講座 ) とは、負債や信用取引の記録を保持するもの。ある顧客について、そ

の銀行における現在の財務状況を示す。

文学コンテキスト

アカウント (報告書 ) とは、ある期間における、関連する出来事についての文章を集めた

もの。


境界づけられたコンテキスト

4-5. コンテキストマップ4. 戦略的 DDD


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-.7 まとめ

ドメインエキスパートそのドメインにおける業務知識を最も持つ人ユビキタス言語ドメインエキスパートやソフトウェア開発者を含めたチーム全体でつくり上げる言語のこと。境界づけられたコンテキストユビキタス言語が使われるコンテキストを明示したもの。コンテキストマップドメインの世界地図

4. 戦略的 DDD

休憩 5min

5. 戦術的 DDD

5. 戦術的 DDD


DDDの思想1 ドメインモデルを中心とした世界

戦略的DDD2 どうやってモデリングするか？

戦術的DDD3 どうやってモデルを実現するか？

5-1. 概要

ドメインモデル中心の世界をアプリケーション上で実現するための戦術。パターン・ランゲージや、アーキテクチャの話はここから出てくる。10 年たった今でもどうやって実装するか議論が重ねられている。

5. 戦術的 DDD


ドメインをアプリケーションの都合から隔離すること。ドメインをモデルを用いて豊かに表現すること。

ドメインを隔離するためのアーキテクチャ：レイヤードアーキテクチャ

ドメインを表現するパターン・ランゲージ： Entity, Servic …

5-2. レイヤードアーキテクチャ

アプリケーションの責務をレイヤーに分割上位のレイヤーは下位のレイヤーに依存する下位のレイヤーは上位のレイヤーに依存してはならない

5. 戦術的 DDD

5-2. レイヤードアーキテクチャ 5. 戦術的 DDD

• アプリケーションの責務をレイヤーに分割• 上位のレイヤーは下位のレイヤーに依存する• 下位のレイヤーは上位のレイヤーに依存してはならない


+ ユーザーに情報を表示して、ユーザーのコマンドを解釈する責務を負う。外部アクタは人間のユーザーではなく、別のコンピューターシステムのこともある。+ 例 ) View, API

5. 戦術的 DDD


+ ユースケース ( シナリオ ) を定義し、ドメインオブジェクトが問題を解決するように導く。ビジネスルールや知識を含まず、やるべき作業を調整するだけ。実際の処理は下位のレイヤーに以上する。+ 例： Controller, Rake, API の実装 , ApplicationService

5. 戦術的 DDD


コントローラーとアプリケーションサービスの責務の違い# コントローラー+ HTTP リクエストを受信して然るべきアプリケーションサービスに渡す。+ アプリケーションサービスから、 HTTP レスポンスを返す。# アプリケーションサービス+ ユースケースを定義する+ ドメインオブジェクトが問題を解決するように調整する。

5. 戦術的 DDD


+ ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの+ ユビキタス言語で作られるべきである。+ Entity, Service, ValueObject, Factory, Repository 等がいる。+ ソフトウェアの核心である。+ UI層にドメインが漏れだすことは許されない。

5. 戦術的 DDD


+ 上位のレイヤーを支える技術的機能を提供する。+ 例： HTTP 、 MySQL 、外部 API 、 ActiveRecord 、 Rails 等

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

Entity オブジェクトのライフサイクルにおいて一意性を保つ必要があるオブジェクトValueObject一意性を持たないオブジェクトRepositoryオブジェクトの永続化のインターフェースを提供するAggregate集約Factory複雑なオブジェクトを組み立てる。Serviceオブジェクトの振舞には収まらない操作。


同一性を保持する必要のあるドメインオブジェクト属性が変わっても、同一性が必要。属性が同じでも、区別したいオブジェクト例： User, Product, Company

5. 戦術的 DDD

5-4. Entity

5. 戦術的 DDD

5-4. Entity

属性が変わっても同一性を保ちたい。

5. 戦術的 DDD

Entity オブジェクトのライフサイクルにおいて一意性を保つ必要があるオブジェクトValueObject一意性を持たないオブジェクトRepositoryライフサイクルの中長期的な保存の責務をおうAggregate集約Factory複雑なオブジェクトを組み立てる。Serviceオブジェクトの振舞には収まらない操作。


Entity とは逆に、例えば「色」や「量」のように、属性だけが重要で、アイデンティティを考えるひつようのないオブジェクト属性が同じならば、同じと考える。例： Red, Email, Age, Money

5. 戦術的 DDD

5-4. ValueObject

5. 戦術的 DDD

5-5. ValueObject

属性が同じならば、同じ

5. 戦術的 DDD

Entity オブジェクトのライフサイクルにおいて一意性を保つ必要があるオブジェクトValueObject一意性を持たないオブジェクトRepositoryオブジェクトの永続化のインターフェースを提供するAggregate集約Factory複雑なオブジェクトを組み立てる。Serviceオブジェクトの振舞には収まらない操作。


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. 問題



+ ドメインモデルを中心に考える設計思想+ ドメインとは、組織が行う事業やそれを取り巻く世界のこと。+ ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。 -> OOP のモデルと理解して OK


第二回実践ドメイン駆動設計Rails × MicroService

× DDD2016 年 5月中


ありがとうございました。