![3.DDDの目的
3-2. 歴史
ソフトウェア危機（ソフトウェアきき、
Software Crisis）とは、ソフトウェア工学がま
だ十分に確立していなかった頃、よく使われた
言葉である[1]。この言葉は、コンピュータの急
激な高性能化によってコンピュータ上のシステ
ムが扱う問題が益々複雑化することによる影響
を表したものである。](https://image.slidesharecdn.com/fincrubydddstudyfirst-160421153314/85/FiNC-DDD-30-320.jpg)
FiNC DDD第一回勉強会
- 2. 1. はじめに 2. DDDとは何か 3. DDDの目的 4. 戦略的DDD 5. 戦術的DDD 0. 目次
- 3. 1. はじめに 背景
- 4. 1. はじめに 「DDD 勉強会 企業」とかで出てきた会社
- 8. 2. DDDとは？ 2-1. 概要 + ドメイン駆動設計(Domain Driven Design) + ドメインモデルを中心に考える設計思想 + ドメインとは、組織が行う事業やそれを取り巻く世界のこと。 + ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。 -> OOPのモデルと理解してOK
- 12. 2. DDDとは？ 2-2. 具体例（コンビニ） 登場モデル 顧客、レジ、商品 1. 顧客モデル 属性：お金 振舞：購入する 2. レジモデル 属性：お金、購入履歴 振舞：購入履歴を登録する。レシートを吐き出す。 3. 商品モデル 属性：お金、名前 振舞：なし
- 14. 2. DDDとは？ 2-2. 具体例（コンビニ） お金モデル、レシートモデル、購入履歴モデル等 が足りない。 -> ドメインへの理解の深化
- 18. 2. DDDとは？ 2-3. 問題 ドメイン駆動設計 (Domain Driven Design)
- 25. 2. DDDとは？ 2-4. まとめ + ドメイン駆動設計(Domain Driven Design) + ドメインモデルを中心に考える設計思想 + ドメインとは、組織が行う事業やそれを取り巻く世界のこと。 + ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。 + ドメインモデルは言語 + DDDは言葉を大切にする設計思想
- 34. 3.DDDの目的 3-2. 歴史 1990年代 オブジェクト指向時代 (Java: 1990年代前半、Python: 1991年、 Ruby: 1995年)
- 35. 3.DDDの目的 3-2. 歴史 1990年代 ソフトウェアプロセス （Extrem Programming/ アジャイル開発プロセス）
- 40. 3.DDDの目的 3-4. まとめ + DDDの目的は、ソフトウェアの核心にある複 雑性と闘うこと。 + OOPやXP等といったソフトウェア工学を体系 化したもの。 + つまり、アジャイルでオブジェクト指向の恩恵 を最大限受けるアプリケーションの考え方。
- 41. 休憩 5min
- 43. 5-1. 概要 5. 戦術的DDD DDDの思想1 ドメインモデルを中心とした世界 戦略的DDD2 どうやってモデリングするか？ 戦術的DDD3 どうやってモデルを実現するか？
- 44. 4-1. はじめに 4. 戦略的DDD 抽象的でnew ワード が出てきます。。
- 48. 4-1. はじめに 4. 戦略的DDD 覚えてもらいたい言葉 1. ドメインエキスパート 2. ユビキタス言語 3. 境界づけられたコンテキスト 4. コンテキストマップ
- 50. 4-1. はじめに 4. 戦略的DDD 覚えてもらいたい言葉 1. ドメインエキスパート 2. ユビキタス言語 3. 境界づけられたコンテキスト 4. コンテキストマップ
- 51. 4-2. ドメインエキスパート + そのドメインにおける業務知識を最も持つ人 + ソフトウェア開発者の仕事は、ドメインエキスパートのメンタルモデ ルアプリケーション上で実現することが仕事 + ※ メンタルモデルとは、人間が実世界で何かがどのように作用するか を思考する際のプロセスを表現したもの 4. 戦略的DDD 食事指導のドメインエキスパート 人事のドメインエキスパート
- 52. 4-3. ユビキタス言語 4. 戦略的DDD 覚えてもらいたい言葉 1. ドメインエキスパート 2. ユビキタス言語 3. 境界づけられたコンテキスト 4. コンテキストマップ
- 53. 4-3. ユビキタス言語 + ドメインエキスパートやソフトウェア開発者を含めたチーム全体でつ くり上げる言語のこと。 + ユビキタス言語が注目するのは、その業務自体が、どのような考えの もとでどのように動くのか。 4. 戦略的DDD StartUpMessageとは？ InternalPaymentとは？ CorporateSurveyDetailとは？ CompanyAnalysisTraitとは？ 専門的な例 抽象的な例 Userとは？ Managerとは？ ProtoTypeとは？ Planとは？ ユビキタス言語が構築されていれば問題ない
- 59. 4-3. ユビキタス言語 4. 戦略的DDD ◯他社事例(どこか忘れました) ドメインエキスパートに、モデルのインターフ ェース(属性とpublicなメソッド)をコードレビ ューしてもらうらしい。
- 60. 4-4. 境界づけられたコンテキスト 4. 戦略的DDD 覚えてもらいたい言葉 1. ドメインエキスパート 2. ユビキタス言語 3. 境界づけられたコンテキスト 4. コンテキストマップ
- 64. 4-5. コンテキストマップ 4. 戦略的DDD 覚えてもらいたい言葉 1. ドメインエキスパート 2. ユビキタス言語 3. 境界づけられたコンテキスト 4. コンテキストマップ
- 66. 4-5-1. コンテキストマップの作り方 1. ドメインエキスパートを横に用意する 2. サービスが解決したいドメインを定義 3. ドメインを機能のまとまりに沿ってサブドメインに分割する 4. サブドメインの集合をユビキタス言語の境界で切り分ける 5. 境界づけられたコンテキスト間の上流と下流の関係を書く 6. サブドメイン内で登場するドメインモデルを定義する 4. 戦略的DDD
- 76. 4-5-1. コンテキストマップの作り方 1. ドメインエキスパートを横に用意する 2. サービスが解決したいドメインを定義 3. ドメインを機能のまとまりに沿ってサブドメインに分割する 4. サブドメインの集合をユビキタス言語の境界で切り分ける 5. 境界づけられたコンテキスト間の上流と下流の関係を書く 6. サブドメイン内で登場するドメインモデルを定義する 4. 戦略的DDD
- 87. 休憩 5min
- 89. 5-1. 概要 5. 戦術的DDD DDDの思想1 ドメインモデルを中心とした世界 戦略的DDD2 どうやってモデリングするか？ 戦術的DDD3 どうやってモデルを実現するか？
- 93. 5-2. レイヤードアーキテクチャ 5. 戦術的DDD • アプリケーションの責務をレ イヤーに分割 • 上位のレイヤーは下位のレイ ヤーに依存する • 下位のレイヤーは上位のレイ ヤーに依存してはならない
- 94. 5-2. レイヤードアーキテクチャ + ユーザーに情報を表示して、ユーザーのコマンドを解釈す る責務を負う。外部アクタは人間のユーザーではなく、別 のコンピューターシステムのこともある。 + 例) View, API 5. 戦術的DDD
- 95. 5-2. レイヤードアーキテクチャ + ユースケース(シナリオ)を定義し、ドメインオブジェクト が問題を解決するように導く。ビジネスルールや知識を含 まず、やるべき作業を調整するだけ。実際の処理は下位の レイヤーに以上する。 + 例：Controller, Rake, APIの実装, ApplicationService 5. 戦術的DDD
- 96. 5-2. レイヤードアーキテクチャ コントローラーとアプリケーションサービスの責務の違い # コントローラー + HTTPリクエストを受信して然るべきアプリケーションサービスに渡す。 + アプリケーションサービスから、HTTPレスポンスを返す。 # アプリケーションサービス + ユースケースを定義する + ドメインオブジェクトが問題を解決するように調整する。 5. 戦術的DDD
- 98. 5-2. レイヤードアーキテクチャ + ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの + ユビキタス言語で作られるべきである。 + Entity, Service, ValueObject, Factory, Repository等がいる。 + ソフトウェアの核心である。 + UI層にドメインが漏れだすことは許されない。 5. 戦術的DDD
- 99. 5-2. レイヤードアーキテクチャ + 上位のレイヤーを支える技術的機能を提供する。 + 例：HTTP、MySQL、外部API、ActiveRecord、Rails等 5. 戦術的DDD
- 102. 5. 戦術的DDD 5-3. 問題
- 116. 休憩 5min
- 120. 同一性を保持する必要のあるドメインオブジェクト 属性が変わっても、同一性が必要。 属性が同じでも、区別したいオブジェクト 例：User, Product, Company 5. 戦術的DDD 5-4. Entity
- 123. Entityとは逆に、例えば「色」や「量」のように、属性だ けが重要で、アイデンティティを考えるひつようのない オブジェクト 属性が同じならば、同じと考える。 例：Red, Email, Age, Money 5. 戦術的DDD 5-4. ValueObject
- 126. 5. 戦術的DDD 5-6. Repository いわゆるリポジトリババア それだけ重要。 ライフサイクルの中長期的な保存の責務を負う。 SQL発行等はInfra層 インターフェースだけ提供
- 128. 5. 戦術的DDD 5-7. Aggregate いわゆる集約。 モチベーションは、関連を最小限に抑えること。 -> 関係性の爆発的増加もある程度制限される。 -> 関係性の境界を引くことが大切。 -> 集約
- 132. 5. 戦術的DDD 5-9. Service 時には単純に「物」に出来上に事もある。 概念的にオブジェクトに属さない操作をサービスと呼ぶ 。 サービスは、関数(状態を持たない。) 例：ScoringService, ShuffleService
- 134. 5. 戦術的DDD 5-10. 問題
- 136. 2. DDDとは？ 2-1. 概要 + ドメイン駆動設計(Domain Driven Design) + ドメインモデルを中心に考える設計思想 + ドメインとは、組織が行う事業やそれを取り巻く世界のこと。 + ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。 -> OOPのモデルと理解してOK
- 137. 2. DDDとは何か? 第二回 実践ドメイン駆動設計 Rails × MicroService × DDD 2016年5月中