FiNC社内のDDD勉強会のスライドです。

1. 第一回DDD勉強会
2016/04/14
株式会社FiNC 重村 裕紀(Rubyエンジニア)

2. 1. はじめに
2. DDDとは何か
3. DDDの目的
4. 戦略的DDD
5. 戦術的DDD
0. 目次

3. 1. はじめに
背景

4. 1. はじめに
「DDD 勉強会 企業」とかで出てきた会社

5. 1. はじめに
Rubyの構文は表現機能が非常に高く、この言語の基礎水準はDDDにと
って最適です。Railsでは、遂に、1990年代前半のWeb以前のUI作成技
術と同じような簡単なウェブUIの作成を実現しているということなの
で、私は非常に期待をもっています。
Rubyの使用によってこの方向に進んでいけば、(おそらく、若干のイン
フラストラクチャ部品による補強は必要ですが)DDDを実現する理想的
なプラットフォームも提供されるようになると考えています。
エリック・エヴァンス曰く…
DDDとRubyは相性良いらしい。

6. 1. はじめに
DDDの概念をわかり
やすく伝えます。

7. 2. DDDとは何か?
2. DDDとは何か?

8. 2. DDDとは？
2-1. 概要
+ ドメイン駆動設計(Domain Driven Design)
+ ドメインモデルを中心に考える設計思想
+ ドメインとは、組織が行う事業やそれを取り巻く世界のこと。
+ ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。
-> OOPのモデルと理解してOK

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

10. 2. DDDとは？
2-2. 具体例（コンビニ）
コンビニのレジシステムを表現して下さい。
2min

11. 2. DDDとは？
2-2. 具体例（コンビニ）
DDDではモデルを用いて表現する。

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

13. 2. DDDとは？
2-1. 概要

14. 2. DDDとは？
2-2. 具体例（コンビニ）
お金モデル、レシートモデル、購入履歴モデル等
が足りない。
-> ドメインへの理解の深化

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

16. 2. DDDとは？
2-2. 具体例（コンビニ）
ドメインを考えるときに、これらのモデルを使っ
てドメインエキスパートとコミュニケーションを
する。
ドメインモデルは、(ユビキタスな)言語である。
DDDは言葉を大切にする設計思想。

17. 2. DDDとは？
2-3. 問題
DDDはなんの略？

18. 2. DDDとは？
2-3. 問題
ドメイン駆動設計
(Domain Driven Design)

19. 2. DDDとは？
2-3. 問題
ドメインとは？

20. 2. DDDとは？
2-3. 問題
組織が行う事業やそれ
を取り巻く世界のこと
。

21. 2. DDDとは？
2-3. 問題
ドメインモデルとは
？

22. 2. DDDとは？
2-3. 問題
ドメインモデルとは、そのドメイ
ンの知識や振舞を抽象化したもの
。

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

24. 2. DDDとは？
2-1. 概要
ドメインモデルを中
心に考える設計思想

25. 2. DDDとは？
2-4. まとめ
+ ドメイン駆動設計(Domain Driven Design)
+ ドメインモデルを中心に考える設計思想
+ ドメインとは、組織が行う事業やそれを取り巻く世界のこと。
+ ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。
+ ドメインモデルは言語
+ DDDは言葉を大切にする設計思想

26. 3.DDDの目的
3. DDDの目的

27. 3.DDDの目的
3-1. 結論
ソフトウェアの核心に
ある複雑性と闘うこと
。

28. 3.DDDの目的
3-2. 歴史
ソフトウェアの歴史

29. 3.DDDの目的
3-2. 歴史
1960年代末
ソフトウェア危機

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

31. 3.DDDの目的
3-2. 歴史
-> ソフトウェア工学の誕生

32. 3.DDDの目的
3-2. 歴史
1970年代
構造化の時代
(if文やfor文使えみたいな？
モジュール作れみたいな？)

33. 3.DDDの目的
3-2. 歴史
1980年代
沈滞期
(管理技術へのシフト)

34. 3.DDDの目的
3-2. 歴史
1990年代
オブジェクト指向時代
(Java: 1990年代前半、Python: 1991年、
Ruby: 1995年)

35. 3.DDDの目的
3-2. 歴史
1990年代
ソフトウェアプロセス
（Extrem Programming/ アジャイル開発プロセス）

36. 3.DDDの目的
3-2. 歴史
2000年代
静的解析技術
(UML)

37. 3.DDDの目的
3-2. 歴史
2003年
エリック・エバンスの
ドメイン駆動設計

38. 3.DDDの目的
3-2. 歴史
DDDは、オブジェクト指向や
エクストリームプログラミン
グなどを体系化したもの。

39. 3.DDDの目的
3-3. 問題
DDDの目的は？

40. 3.DDDの目的
3-4. まとめ
+ DDDの目的は、ソフトウェアの核心にある複
雑性と闘うこと。
+ OOPやXP等といったソフトウェア工学を体系
化したもの。
+ つまり、アジャイルでオブジェクト指向の恩恵
を最大限受けるアプリケーションの考え方。

41. 休憩 5min

42. 4. 戦略的DDD
4. 戦略的DDD

43. 5-1. 概要
5. 戦術的DDD
DDDの思想1 ドメインモデルを中心とした世界
戦略的DDD2 どうやってモデリングするか？
戦術的DDD3 どうやってモデルを実現するか？

44. 4-1. はじめに
4. 戦略的DDD
抽象的でnew ワード
が出てきます。。

45. 4-1. はじめに
4. 戦略的DDD
一番とっつきづらい
。

46. 4-1. はじめに
4. 戦略的DDD
しかし、一番大切

47. 4-1. はじめに
4. 戦略的DDD
ドメイン中心の世界
↓
戦略的DDD
(どうやってドメインをモデルで表すか？)
↓
戦術的DDD
(どうやって実装するのか？)

48. 4-1. はじめに
4. 戦略的DDD
覚えてもらいたい言葉
1. ドメインエキスパート
2. ユビキタス言語
3. 境界づけられたコンテキスト
4. コンテキストマップ

49. 4-1. はじめに
4. 戦略的DDD
後で聞きます！

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とは？
ユビキタス言語が構築されていれば問題ない

54. 4-3. ユビキタス言語
ドメインエキスパートやソフトウェア開発者を含めたチーム全
体でつくり上げる共有言語。
4. 戦略的DDD
ユビキタス言語
ドメインエキスパートソフトウェア開発者
デザインパターン
技術用語
開発者が理解していない
ビジネス用語
設計には出てこないが誰もが
使用するビジネス用語

55. 4-3. ユビキタス言語
4. 戦略的DDD
この状況をコードで記述して下さい。1min

56. 4-3. ユビキタス言語
4. 戦略的DDD
「どうでもいいから、さっさとコード書こうよ。」

57. 4-3. ユビキタス言語
4. 戦略的DDD
「インフルエンザの注射を患者に打つ。」

58. 4-3. ユビキタス言語
4. 戦略的DDD
「ナースが患者に、インフルエンザワクチンを投与する。」

59. 4-3. ユビキタス言語
4. 戦略的DDD
◯他社事例(どこか忘れました)
ドメインエキスパートに、モデルのインターフ
ェース(属性とpublicなメソッド)をコードレビ
ューしてもらうらしい。

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

61. 4-4. 境界づけられたコンテキスト
ユビキタス言語が使われるコンテキストを明
示したもの。
境界を明示することで、ユビキタス言語の意
味を定義する。
4. 戦略的DDD

62. 4-4. 境界づけられたコンテキスト
4. 戦略的DDD
銀行取引
コンテキスト
アカウント(講座)とは、負債や信用取引の記
録を保持するもの。ある顧客について、その
銀行における現在の財務状況を示す。
文学
コンテキスト
アカウント(報告書)とは、ある期間における
、関連する出来事についての文章を集めたも
の。

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

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

65. 4-5. コンテキストマップ
ドメインの世界地図
4. 戦略的DDD

66. 4-5-1. コンテキストマップの作り方
1. ドメインエキスパートを横に用意する
2. サービスが解決したいドメインを定義
3. ドメインを機能のまとまりに沿ってサブドメインに分割する
4. サブドメインの集合をユビキタス言語の境界で切り分ける
5. 境界づけられたコンテキスト間の上流と下流の関係を書く
6. サブドメイン内で登場するドメインモデルを定義する
4. 戦略的DDD

67. 4-5. コンテキストマップ
人事評価システム
4. 戦略的DDD

68. 4-5-1-1. ドメインエキスパートを横に用意する。
4. 戦略的DDD
人事評価のドメインエキスパート
人事評価システムを作りたいん
だよね〜

69. 4-5-1-2. サービスが解決したいドメインを定義
4. 戦略的DDD
勤怠
給料
売上成績
他社評価
役職
プロフィール
勤怠や売上、他社からの評価等を元に、
給料や、役職を決定するシステムを作りたい。
人事評価ドメイン

70. 4-5-1-2. サービスが解決したいドメインを定義
4. 戦略的DDD
勤怠や売上、他社からの評価等を元に、
給料や、役職を決定するシステム
人事評価ドメイン

71. 4-5-1-3. ドメインを機能のまとまりに沿ってサブドメインに分割する
4. 戦略的DDD
人事評価ドメイン
従業員アカウント管理サブドメ
イン
集計サブドメイン
評価サブドメ
イン

72. 4-5-1-4. サブドメインの集合をユビキタス言語の境界で切り分ける
4. 戦略的DDD
人事評価ドメイン
従業員アカウント管理サブドメ
イン
集計サブドメイン
評価サブドメ
イン
評価コンテキスト
管理コンテキスト

73. 4-5-1-4. サブドメインの集合をユビキタス言語の境界で切り分ける
4. 戦略的DDD
人事評価ドメイン
従業員アカウント管理サブドメ
イン
集計サブドメイン
評価サブドメ
イン
評価コンテキスト
管理コンテキスト
あくまでユビキタス言語の境界

74. 4-5-1-5. 境界づけられたコンテキスト間の上流と下流の関係を書く
4. 戦略的DDD
人事評価ドメイン
従業員アカウント管理サブドメ
イン
集計サブドメイン
評価サブドメ
イン
評価コンテキスト
管理コンテキスト
U
U U
D
D D

75. 4-5-1-6. サブドメイン内で登場するドメインモデルを定義する
4. 戦略的DDD
集計サブドメイン
Attendance
勤怠
Employee
従業員
OtherCompaniesEvaluation
他社評価
CultureFit
文化共感度
ImprovementOriented
改善志向
EvaluationService
評価サービス

76. 4-5-1. コンテキストマップの作り方
1. ドメインエキスパートを横に用意する
2. サービスが解決したいドメインを定義
3. ドメインを機能のまとまりに沿ってサブドメインに分割する
4. サブドメインの集合をユビキタス言語の境界で切り分ける
5. 境界づけられたコンテキスト間の上流と下流の関係を書く
6. サブドメイン内で登場するドメインモデルを定義する
4. 戦略的DDD

77. 4-5-3. コンテキストマップまとめ
4. 戦略的DDD
ドメインエキスパートとモデ
ルを通じて会話し、ユビキタ
ス言語を構築すること。

78. 4-6. 問題
4. 戦略的DDD
ドメインエキスパートとは
？

79. 4-6. 問題
4. 戦略的DDD
そのドメインにおける業務
知識を最も持つ人

80. 4-6. 問題
4. 戦略的DDD
ユビキタス言語とは？

81. 4-6. 問題
4. 戦略的DDD
ドメインエキスパートやソ
フトウェア開発者を含めた
チーム全体でつくり上げる
共有言語。

82. 4-6. 問題
4. 戦略的DDD
境界づけられたコンテキス
トとは？

83. 4-6. 問題
4. 戦略的DDD
ユビキタス言語が使われるコンテ
キストを明示したもの。

84. 4-6. 問題
4. 戦略的DDD
コンテキストマップとは？

85. 4-6. 問題
4. 戦略的DDD
ドメインの世界地図

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

87. 休憩 5min

88. 5. 戦術的DDD
5. 戦術的DDD

89. 5-1. 概要
5. 戦術的DDD
DDDの思想1 ドメインモデルを中心とした世界
戦略的DDD2 どうやってモデリングするか？
戦術的DDD3 どうやってモデルを実現するか？

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

91. 5-1. 概要
5. 戦術的DDD
ドメインをアプリケーションの都合から隔離すること。
ドメインをモデルを用いて豊かに表現すること。
ドメインを隔離するためのアーキテクチャ：レイヤードアーキテクチャ
ドメインを表現するパターン・ランゲージ：Entity, Servic …

92. 5-2. レイヤードアーキテクチャ
アプリケーションの責務をレイヤーに分割
上位のレイヤーは下位のレイヤーに依存する
下位のレイヤーは上位のレイヤーに依存してはならない
5. 戦術的DDD

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

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

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

99. 5-2. レイヤードアーキテクチャ
+ 上位のレイヤーを支える技術的機能を提供する。
+ 例：HTTP、MySQL、外部API、ActiveRecord、Rails等
5. 戦術的DDD

100. 5-2. レイヤードアーキテクチャ
5. 戦術的DDD
ドメイン層とインフラ層を分
けることでDBリファクタ(正規
化、キャッシュテーブル、マ
イクロサービス)をしても、ビ
ジネスロジックが変わらなけ
ればドメイン層には影響がな
い。

101. 5-3. 問題
レイヤードアーキテクチャ
の構成は？
5. 戦術的DDD

102. 5. 戦術的DDD
5-3. 問題

103. レイヤードアーキテクチャ
のルールは？
5. 戦術的DDD
5-3. 問題

104. アプリケーションの責務をレイヤーに分割
上位のレイヤーは下位のレイヤーに依存する
下位のレイヤーは上位のレイヤーに依存してはならない
5. 戦術的DDD
5-3. 問題

105. UI層の責務は？
5. 戦術的DDD
5-3. 問題

106. ユーザーに情報を表示して、ユーザーの
コマンドを解釈する責務を負う。外部ア
クタは人間のユーザーではなく、別のコ
ンピューターシステムのこともある。
5. 戦術的DDD
5-3. 問題

107. Application層の責務は？
5. 戦術的DDD
5-3. 問題

108. ユースケース(シナリオ)を定義し、ドメインオブジ
ェクトが問題を解決するように導く。ビジネスルー
ルや知識を含まず、やるべき作業を調整するだけ。
実際の処理は下位のレイヤーに以上する。
5. 戦術的DDD
5-3. 問題

109. Domain層の責務は？
5. 戦術的DDD
5-3. 問題

110. ドメインモデルとは、そのドメインの知識
や振舞を抽象化したもの
5. 戦術的DDD
5-3. 問題

111. Infrastructure層の責務は？
5. 戦術的DDD
5-3. 問題

112. 上位のレイヤーを支える技術的機能を提
供する。
5. 戦術的DDD
5-3. 問題

113. なぜInfrastructure層とDomain
層を分けるべきか？
5. 戦術的DDD
5-3. 問題

114. 上位のレイヤーを支える技術的機能を提
供する。
5. 戦術的DDD
5-3. 問題

115. ビジネスロジックと、技術的な関心
事を疎結合にすることでドメインを
中心とした世界を作る。
5. 戦術的DDD
5-3. 問題

116. 休憩 5min

117. ドメインモデルを豊かに表現する。
5. 戦術的DDD
5-4. パターン・ランゲージ

118. ドメインモデルを豊かに表現する。
5. 戦術的DDD
5-4. パターン・ランゲージ

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

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

121. 5. 戦術的DDD
5-4. Entity
属性が変わっても同一性を保ちたい。

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

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

124. 5. 戦術的DDD
5-5. ValueObject
属性が同じならば、同じ

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

126. 5. 戦術的DDD
5-6. Repository
いわゆるリポジトリババア
それだけ重要。
ライフサイクルの中長期的な保存の責務を負う。
SQL発行等はInfra層
インターフェースだけ提供

127. 5. 戦術的DDD
5-6. Repository
ただ、冷凍するだけ。
ただ、解答するだけ。
Validationはドメインオブ
ジェクト自身が持つ。

128. 5. 戦術的DDD
5-7. Aggregate
いわゆる集約。
モチベーションは、関連を最小限に抑えること。
-> 関係性の爆発的増加もある程度制限される。
-> 関係性の境界を引くことが大切。
-> 集約

129. 5. 戦術的DDD
5-7. Aggregate
・集約のルートエンティティは、
グローバルな同一性を持つ。
・集約の境界外から境界内部のオ
ブジェクトにアクセスしてはいけ
ない。
・境界内部には集約ルートのみア
クセスできる。
自動車
集約ルート
シート
エンジン
タイヤ
集約ルートを介さず
アクセスしてはいけない。
アクセスできる。

130. 5. 戦術的DDD
5-8. Factory
複雑なオブジェクトをただ組み立てるだけ。
Repositoryは、ただ冷凍と解凍のインターフェースのみ提供。
Factoryはオブジェクトを組み立てるだけ。
Repositoryの内部で呼び出されることもある。

131. 5. 戦術的DDD
5-8. Factory
永続化とは関係ない。
ただ複雑なオブジェクト
を組み立てるだけ。
まあ、あんまり使わない
。

132. 5. 戦術的DDD
5-9. Service
時には単純に「物」に出来上に事もある。
概念的にオブジェクトに属さない操作をサービスと呼ぶ
。
サービスは、関数(状態を持たない。)
例：ScoringService, ShuffleService

133. 5. 戦術的DDD
5-9. Service
Rubyならばインスタンス化しても良いが、基本的には状態を持たない関数
まずは、ドメインオブジェクトの振舞にもたせられないか考えるべし。

134. 5. 戦術的DDD
5-10. 問題

135. 2. DDDとは何か?
2. DDDとは何か?

136. 2. DDDとは？
2-1. 概要
+ ドメイン駆動設計(Domain Driven Design)
+ ドメインモデルを中心に考える設計思想
+ ドメインとは、組織が行う事業やそれを取り巻く世界のこと。
+ ドメインモデルとは、そのドメインの知識や振舞を抽象化したもの。
-> OOPのモデルと理解してOK

137. 2. DDDとは何か?
第二回
実践ドメイン駆動設計
Rails × MicroService
× DDD
2016年5月中

138. 2. DDDとは何か?
ありがとうございました
。