幾つかのスライドを削除して公開

1. ドメイン駆動設計とScala
〜既存プロジェクトへの適用〜
Fumiyasu Sumiya

2. 対象・目的
既存プロジェクトにDDDを適用させてカオスからの脱却
と、Scalaの紹介

3. アジェンダ
1. 自己紹介
2. HRMOS紹介
3. 本編
4. 締め
3

4. DDDの話 7割
Scalaの話 3割
のつもりだった
本編について
4

5. アジェンダ
1. 自己紹介
2. HRMOS紹介
3. 本編
4. 締め
5

6. 自己紹介
6
角谷 文康（すみや ふみやす） @FScoward
■ 略歴
2011年4月 ～ 2015年7月
TIS株式会社にてクレジットカードシステムの保守開発・新規開発などに従事
- 2014年2月 デブサミ2014登壇
2015年8月
株式会社ビズリーチ入社
2015年8月 ～ 2015年12月
スタンバイ のサーバーサイドエンジニア
2016年1月 ～ 現在
HRMOS採用管理 のサーバーサイドエンジニア
2016年12月（予定）
JJUG CCC
■ 好きなもの
スフィア、乃木坂46、欅坂46

7. アジェンダ
1. 自己紹介
2. HRMOS紹介
3. 本編
4. 締め
7

8. 8
https://www.hrmos.co/
HRMOS紹介

9. アジェンダ
1. 自己紹介
2. HRMOS紹介
3. 本編
4. 締め
9

10. 2016年1月～HRMOS採用管理に参画
この時点でかなり、モノとして形になっていた
HRMOSへの参画
10

11. ドメイン駆動設計は取り入れていなかった
機能追加しようとするとかなり作りが複雑になっている部分があって、精神的に辛い
部分があった
今後どんどんと機能追加して使いやすくしていかなければならない
HRMOS採用管理システム
11

12. 今後もどんどん機能追加を行っていく必要があるので、なんとかして複雑性に立ち向
かわなければならない
HRMOS採用管理システム（課題）
12

13. 設計時に仕様をまとめてConfluenceにまとめてはあったものの、各自好きな形式で作
成していたり、あまりメンテナンスがなされずにいた。
コードも結構複雑なものになってしまっていて、機能追加するのが少しきつい（コードを
読んでもイマイチなにをやっているのかがわからない）ような部分も一部存在してい
た。
HRMOS採用管理システム（その他問題点）
13

14. 今後のためにも
最低限整備しておかないとまずい

15. どこから手を付けるべきか迷ったが、まずは設計仕様の様式を決めてしまおうと思っ
た
設計仕様の様式
15

16. 最低限、なんでこの仕様にしたんだっけ？というのが辿れれば良い
求めるもの
16

17. ■ 出会ったのは Mini Spec という書き方
● 「ペロリ流 開発要件のまとめ方」
● http://tech.pero.li/entry/2016/07/22/141228
設計仕様のドキュメントの統一
17

18. 設計の仕様の書き方についてはどうにかなりそうな雰囲気が出てきたが・・・
実装の複雑性はどうしようか

19. 19
複雑性に立ち向かう

20. HRMOS採用管理シ
ステム
（課題）

23. DDD!!!
23

24. 複雑性はどこから？
24
多くのアプリケーションにおいて、最も重要な複雑さは、技術的なものではない。 複雑
なのはドメインそのもの、すなわち、ユーザの活動やビジネス なのである。ドメインの
持つこの複雑さが設計で扱われないのであれば、基盤となる技術が適切に考えられ
ていたとしても意味がない。設計を成功させるためには、ソフトウェアにおけるこの中
心的な側面を、体系的に扱わなければならない。
エリック・エヴァンスのドメイン駆動設計 まえがき 複雑さという課題

25. 25
設計の時点でスパゲッティコードは運命づけられている

26. Why DDD?
26
ドメイン意識
常にドメインモデルを意識した設計を行うので、行き過ぎた単純化・汎用化を
防ぐことが出来る
複雑性に立ち向かう
なんちゃらServiceにビジネスロジックをまとめ、ごちゃごちゃして複雑になり、
肥大化するのを防ぐことが出来る
責務を明確に
Entityに正しく処理をもたせることが出来るため、誰が何をするのかが明確に
なる（処理が各所に散らばらない）

27. Why DDD?
機能実現のためのコードとビジネスロジックは綺麗に分離されていないと、機
能追加やバグ修正の時に非常につらい思いをする。
27
設計思想の統一
思想がないと実装者、レビュワーによってコードの実装に偏りが生じる
※ 毎回全員がレビューしてるなら別
ビジネスロジックへの
集中
ScalaとDDDは相性が
いいらしい
はてなさんもDDDをやりやすくするためにScalaを使ったらしい

28. Why DDD?（精神面）
■ 「ソフトウェアの核心にある複雑性に立ち向かう」 ← かっこいい
■ SIerに居た頃は業務がどうなってようが、知ったこっちゃない。言われたと
おりに動くものが作れればOKという感じだったが、それが嫌になって事業
会社に転職したので、きちんと業務を理解して、あるべき姿のきれいなシス
テム作りをしたかった
■ 我々”一般的な”技術者が解決しなければならないのは技術的問題の前
に、ビジネスの問題であるということを認識しなければならない。
28

29. 29
■ ”一般的な”と強調しているのは、スペシャリストはスペシャリストでもちろん
必要なのでそれとは違う技術者と明確に区別するため
■ スペシャリストになれるのはほんの一握り
そこで勝負できない以上、自分の得意分野を見つけてそこで活躍できるよ
うになればいいと思ってます
注意

30. ■ 技術的な話は勿論必要だけど、ビジネスとしてやるのなら技術の前にビジ
ネスに即してなくちゃだめだよね？
■ 技術者をやっているとどうしてもテクニックの話によりがちだけど技術は手
段であって目的ではないよね？
■ 正しく設計出来てる？？？
■ ソースコード読んでもなにやってるかわからない。何をしなければいけない
のかわからないってどうなの？
■ 技術的にではなく、ビジネス的に本来の目的を満たしている？
個人的意見
30

31. Scalaでドメイン駆動設計？
31
■ Scalaは静的型付け言語なのでドメイン駆動設計と相性がいい（と個人的に
は思っている）
■ ちなみにEric Evans本人はRubyが相性が良いかもねと言っている。
● https://www.infoq.com/jp/articles/eric-evans-ddd-matters-today
● 理由としてはrubyがドメイン固有言語（DomainSpecificLanguage）を簡単に作成できる点にあ
る。
● ドメイン駆動での開発はDSLでメタプログラミングでシステムを作ることなのかもしれない。
● DSLについて語るつもりはない（というか語れるほど詳しくない）ので、各自調べてみてくださ
い。
● http://www.slideshare.net/yizawa/rubydsl-25541986

32. 先ず、隗より始めよ
とりあえずDDDの本を読んで、ネットの記事もいろいろと漁った。
でも実務にどう当てはめていくのかが全くわからないから
広めることもできない。
であれば、まずはやってみよう！

33. データモデルが既にあるので、リバースエンジニアリングの形のようになったが、とり
あえずドメインモデル図を描いてみることにしたが、なんかいまいちなドメインモデル
図が出来上がった。
ドメインモデル図に挑戦
33

34. 新規機能を開発するときに、局所的なドメインモデル図を描いてみることにした
ドメインモデル図に挑戦 その2
34

35. 35
そもそもドメインモデル図描いてどうなるんだっけ・・・？

36. けれども・・・
36
MiniSpecとドメインモデル図を使って設計レビューを行ったところ、チームとして取り組
んでみようよ、ということにはなった

37. チームでの取り組みに向けて
37
設計時にMini Specと、ドメインモデル図をチームメンバーに描いてもらうようにしてみ
た

38. ところがどっこい
自分で勝手にドメインモデル図を描くのは良かったが、イマイチDDDのことを
知らないチームメンバーに「ドメインモデル図よくわからないから描けないで
す」と言われてしまった

39. 当然の展開
39
HRMOS事業部ではスプリントごと（2週間）に一回事業部共有会というものを設けてお
り、そこで色々と知識を共有することの出来る場が用意されているので、そこでDDDの
エッセンスを紹介すればいいやという程度にしか考えていなかった

40. しかも、やれてる気にはなったが
40
それっぽい図はかけたが、なにも解決していない！
図があったから何なの？感が半端ない

41. DDDはキチンとやらないと意味がない

42. ■ DDDは何が解決できるのか
● ソフトウェアの核心にある複雑性に立ち向かう
■ 何のために用いるのか
● ビジネスロジックへの集中
■ なぜドメインモデルが必要なのか
● 注視すべきものが一体何なのかを明確にする
● チームとして意思形成を測る
再考：DDDとは
42The Power of PowerPoint - thepopp.com

43. 既存のプロジェクトにどう適用すべきか
43
本も読んだし、ネット上の情報も漁った。
でもはじめ方がわからなかったから、よくわからないまま簡単に手を付けられそうなと
ころから初めてしまっていた。

44. やり方を間違えていた
44
ドメインビジョン声明文
↓
境界づけられたコンテキスト
↓
ユビキタス言語
↓
ドメインモデル ←ここからだけで出来るわけがない
↓
ドメインモデル図

45. というかいびつなやり方してた
45
データモデル
↓
ドメインモデル図
↓
ドメインモデル

46. 取り組み方を間違えていたことに気づいた

47. 正しい取り組み方をするようにした
47
ドメインビジョン声明文
↓
境界づけられたコンテキスト
↓
ユビキタス言語
↓
ドメインモデル
↓
ドメインモデル図

48. 0. DDDの根本を理解する
Domain Driven Design

49. DDDとは
49
DDDは業務領域（ドメイン）に注目したパターン
業務に即した形でシステムの構築を行うことで、 ビジネスロジックに集中する ことを目
的としている

50. DDDでなくても機能は満たせる
■ 機能を満たすものだけを作っていくと、どの機能とどの機能が結びついて
いてそれぞれがどう関与しているかという知識がバラバラに散らばることに
なる
■ だからある業務的な処理を変更したいときに本来はすべての処理が同一
にならなければならないのにそれが漏れたりする
■ また、処理的にエラーにはならなくても業務的に間違った処理を行うことに
なったりする
50

51. モデルと実装を結びつける
51
設計が、あるいは設計の中心となる部分が、ドメインモデルに紐付いていないならば、
そのモデルにほとんど価値はなく、ソフトウェアが正確であるかどうかも疑わしい。 同じ
ように、モデルと設計された機能との紐づけが複雑だと理解するのが難しく、実際に
は、設計が変更されたときに紐づけを維持できなくなる。 分析と設計の間に致命的な
亀裂が生じるため、それぞれの作業で得られる洞察は互いに活かされることがないの
だ。
エリック・エヴァンスのドメイン駆動設計 第３章 モデルと実装を結びつける p.46

52. 1. ドメインビジョン声明文を書く
Domain Driven Design

53. ドメインビジョン声明文とは何なのか
53
ドメインビジョン声明文は、開発のあらゆるフェーズで経営陣と、技術系の担当者が直
接使うことが出来て、 リソースの割当やモデリングの選択における指針となり、チーム
メンバの教育にも使われる 。ドメインモデルが仕えるべき対象が多くても、このドキュメ
ントがあれば、それぞれの関心がどうバランスを取られているかがわかる。
エリック・エヴァンスのドメイン駆動設計 第15章 蒸留 p.422

54. ドメインビジョン声明文とは何なのか
54
コアドメインとそれがもたらす価値に関する簡潔な記述を作成すること（約1ページ）。
これが「価値の提議」(value proposition)である。ドメインモデルを他と差別化するもの
でない側面は無視すること。スコープを狭い範囲に留めること。この声明文は早期に
作成し、新しい洞察を得たら改訂すること。
ドメインビジョン声明文は 道標として用いられるもので、開発チームを共通の方向に向
かわせ、モデルとコード自体の蒸留を続けさせる。 技術系ではないチームメンバや経
営陣、さらには顧客とも共有できる のだ。
エリック・エヴァンスのドメイン駆動設計 第15章 蒸留 p.422

55. 55
ドメインビジョン声明文が無いと始まらないので、自分で書くことにした
既存プロジェクトへの適用

56. ドメインビジョン声明文（例）
56
『航空会社予約システム』に関するドメインビジョン声明文の一部
このモデルは乗客の優先順位と航空会社予約戦略を表し、柔軟なポリシーに基づい
てそれらのバランスを取ることができる。乗客のモデルには、航空会社がリピータとの
間に構築しようと努めている「関係性」を反映するべきだ。それゆえ、このモデルは乗
客の履歴を役立つかたちで凝縮して表現しなければならない。こうした履歴としては、
特別プログラムへの参加や、戦略的な企業顧客との提携などがある。
いろいろなユーザの持つさまざまな役割（乗客、職員、経営者）も表現されて、関係性
を表現したモデルを豊かにし、セキュリティフレームワークに必要な情報を与える。モ
デルは、ルートや座席の効率的な検索をサポートしなければならず、すでにある他の
航空会社予約システムとも統合しなければならない。

57. ドメインビジョン声明文（HRMOS採用管理）
57
採用企業と応募者の一連の流れと状態を表し、それに伴う採用業務のサポートを行う
ものとする。応募者のモデルには採用企業が必要としている情報を反映すべきだ。
いろいろなユーザの持つ様々な役割（管理者、採用担当者、採用コーディネータ、面
接官、社員）も表現されて、応募者との関わりを表すことが出来る。
リファラル採用（社員紹介）も可能とし、リファラル採用を促進させるとともに、ダイレク
トリクルーティングを現実のものとするための支援を行うようにすべきだ。
また、採用企業においてはレポートを参照することによって、採用に対して最適なコス
ト配分の意思決定を行うことを可能とし、人事業務を戦略的な仕事へと昇華し、生産
性の高い採用活動を実現する

58. 最初は書けない、でも書いてみることが重要
■ 大切なのは今やろうとしているドメインにおいてなにを差別ポイントとして置
くか
■ もたらす価値とは一体何なのかを明示すること
■ そして、徐々に徐々に洗練させていくこと
■ DDDは小さな改善の積み重ね
● http://masuda220.jugem.jp/?eid=387
58

59. 2. 境界づけられたコンテキスト
Domain Driven Design

60. 境界づけられたコンテキスト
60
コンテキストとは、Wikipediaを見ると以下のように定義されています。
>言語学におけるコンテクストとは、メッセージ(例えば1つの文)の意味、メッセージとメッセージの関係、言語が発せられた場所や時代の社会環境、
言語伝達に関連するあらゆる知覚を意味し、コミュニケーションの場で使用される言葉や表現を定義付ける背景や状況そのものを指す。 例えば日本
語で会話をする2者が「ママ」について話をしている時に、その2者の立場、関係性、前後の会話によって「ママ」の意味は異なる。2人が兄弟なのであ
れば自分達の母親についての話であろうし、クラブホステス同士の会話であれば店の女主人のことを指すであろう 。このように相対的に定義が異な
る言葉の場合は、コミュニケーションをとる2者の間でその関係性、背景や状況に対する認識が共有・同意されていなければ会話が成立しない。この
ような、コミュニケーションを成立させる共有情報をコンテクスト という。
>マーケティングの方法論として、顧客の背景を理解・把握したうえで、それに沿った商品プロモーションを行うことを「コンテクスト・マーケティング」と
呼ぶ。
>情報工学におけるコンテキストは、デバイスが使われている状況を意味する。例えばある時点でデバイスを使用しているユーザーなど。コンテキス
トアウェアネスおよびコンテキストスイッチを参照されたい。
>人工知能におけるコンテキストは、意思伝達、言語学、形而上学などに属する部分と深い関係がある。自動的な推論を使ってそれらの観点が如何
にしてコンピュータシステム上でモデル化できるかは、人工知能の研究テーマの1つである。
>シチュエーション・コメディにおけるコンテクストとは、そのショーが公開されている時代背景やその時点の社会の出来事などを意味する。例えば、"I
love Lucy"には1950年代のアメリカのコンテクストが反映されている。
>心理学におけるコンテクストとは、フォアグラウンドの事象に伴うバックグラウンドの刺激を意味する。例えば、ネズミがネコを恐れながらエサを探し
ているとき、ネコがフォアグラウンドの事象であり、探し回っている場所(および時間)がバックグラウンドの刺激である。海馬にはある種のコンテクスト
処理に特化した神経構造があると考えられている。

61. 境界づけられたコンテキスト
61
対象とする範囲が異なればドメインモデルは意味をなさなくなるということがわかる。
なので、初めに自分たちの定めようとするドメインモデルがどのコンテキストに属する
ものなのかをきちんと定義する必要がある。

62. ドメインを見つけ出し、境界づける
62
自分たちの行う事業のドメインは一体何なのか
採用管理、勤怠管理、評価管理...etc
それぞれ明確な境界があり、採用管理コンテキスト、勤怠管理コンテキストと言った、
各コンテキストを境界づけることが出来る。

63. 63
採用管理システムを作る！となったときに「採用管理」というドメイン定義では
イマイチ曖昧・・・
採用管理って何が出来なくちゃいけないんだっけ？と洗い出すことから始ま
る。そうするともう少し細かいドメインを定義できるようになる。（サブドメイン）
既存プロジェクトへの適用

64. コンテキストマップ
64
コンテキストマップと呼ばれる図を描くことで、それぞれのドメインが担うべき役割を明
確に分けることができて、ドメインモデルがどこに属するかを端的に表すことが出来る
※「境界づける」というのはドメインモデルに明確に区別をつけてドメインモデルを 共有
しないということ

65. コンテキストマップ
65
モデルが適用されるコンテキストを明示的に定義すること。明示的な境界は、チーム
編成、そのアプリケーションに特有の部分が持つ用途、コードベースやデータベース
スキーマなどの物理的な表現などの観点から設定 すること。その境界内では、モデル
を厳密に一貫性のあるものに保つこと。ただし、境界の外部の問題によって注意を逸
らされたり、混乱させられたりするのを避けること。
エリック・エヴァンスのドメイン駆動設計 第１４章 モデルの整合性を維持する p.344

66. 66
マッピングすべきは現状
現状の共有から始め、どうあるべきかをチームで考える
既存プロジェクトへの適用

67. 境界づけられたコンテキスト 超意訳
ことばの定義、意味が変わらない範囲を定めること

68. 3. ユビキタス言語の作成
Domain Driven Design

69. ユビキタス言語とは
69
業務領域についてよく知った人との会話においても お互いに齟齬なく情報を伝え合う
ために用いることが出来る言葉を定義したもの。
システム開発においては、情報伝達の齟齬が発生しておかしなシステムをつくり上げ
ることがままあるが、こういった齟齬をなくすためのプロダクトに関わる全員とスムーズ
に会話を行うための言語のことを作り上げることをやっておく必要がある。

70. ユビキタス言語の作成
70
まずはドメインエキスパートとじっくりと会話をしてお互いのことばが滑らかに立ち止ま
ることなく進むようにお互いの ことばによる理解の齟齬をなくすことを目的として作成
する。
世間一般で通じる言葉を用いる必要はなく、 境界づけられたコンテキスト 内で通じる言
葉が出来ればいい
※ ドメインエキスパートとは、業務領域についての深い知識を持っている人物のこと
であって必ずしも役職者ではない。

71. ユビキタス言語の作成
71
ドメインエキスパートは専門的な用語を用いて語りがちだが、それが本当に求めてい
るものを表しているとは限らない
そういった齟齬をなるべく減らすために自分たちで 言葉を再定義する必要がある
チーム全員がその言葉を聞いて勘違いすることなく、同じ物事を思い浮かべることが
出来るまで言葉を洗練するのが重要

72. きつね？たぬき？
72
■ 関東のたぬきそば
■ 大阪の立ち食いそば屋のたぬきそば

73. きつね？たぬき？
73
Wikipediaより
https://ja.wikipedia.org/wiki/%E3%81%9F%E3%81%AC%E3%81%8D_(%E9%BA%BA%E9%A1
%9E)
関東 関西
きつね 油揚げをのせたそば又はうど
ん
（きつねうどん、きつねそば）
油揚げの甘煮をのせたうどん
（けつね、しのだ）
たぬき 揚げ玉をのせたそば又はうど
ん
（たぬきうどん、たぬきそば）
京都：刻んだ油揚げ[21]と青
ねぎをあんかけにしたうどん
又はそば
大阪：油揚げの甘煮またはキ
ザミをのせたそば

74. きつね？たぬき？（ポルナレフ状態）
74
あ…ありのまま 今 起こった事を話すぜ！
「おれは 大阪の立ち食い蕎麦屋でたぬきそばを頼んだら
なぜか上に油揚げがのっていた」
な… 何を言っているのか わからねーと思うが
おれも 何をされたのか わからなかった…
頭がどうにかなりそうだった… 催眠術だとか超スピードだと
か
そんなチャチなもんじゃあ 断じてねえ
もっと恐ろしいものの片鱗を 味わったぜ…

75. 75
ユビキタス言語の作成に関してはすでに使われている言葉の中から違和感
のあるものを探し出して適切になおしてやれば良い
既存プロジェクトへの適用

76. 4. ドメインモデルを見つけ出す
Domain Driven Design

77. ドメインモデルを見つけ出す
77
ユビキタス言語が作れたらあとは見つけ出したことばたちをドメインモデルとして落と
し込むだけ

78. ドメインモデルに落とし込む
78The Power of PowerPoint - thepopp.com
1. エンティティ(Entity)
2. バリューオブジェクト(ValueObject)
3. 集約(Aggregate)
これら3つの概念を押さえておく必要がある

79. Entity
79
■ Entityは（同一性を）識別することが必要となるモデルのこと
● 簡単に言うと他と区別するためのIDを持たせて管理するということ
■ 同一性を担保出来れば識別子はなんでも良い

80. 80
Entity
田中太郎くん(10歳)と6年後の田中太郎くん(16歳)は同一人物
年齢などの属性が異なるだけ
田中太郎くん（１０）
田中太郎くん（１６）

81. 81
同一性を担保する識別子は何か
名前？年齢？性別？
名前+年齢？名前+年齢+性別？
田中太郎くん（１０） 田中太郎くん（１６） 里中太郎くん（２７）

82. 82
同一性を担保する識別子は何か
識別子は国民総背番号「行政手続における特定の個人を識別するための番号の利
用等に関する法律」で定められたマイナンバー

83. ValueObject
83
■ イミュータブルに保つ（状態を管理しない）
■ 状態を持たないオブジェクトとすることで、複雑性の排除に役立つ

84. Scala講座
■ Scalaでは値は基本的にval（イミュータブル）で宣言するのでValueObjectで
あることを担保しやすくなっている
● ※ var（ミュータブル）で宣言も可能
■ case classもイミュータブル
The Power of PowerPoint - thepopp.com 84

85. Scala講座 〜 case class について 〜
85The Power of PowerPoint - thepopp.com
Scalaでは case class というものがつくれて宣言が簡単になる

86. ValueObject 例え話
86
■ 誕生日をどう表すか
■ 単純にDate型で表すのかBirthDate型を作るか
■ Dateでやると年齢を別の場所で算出しなければならない
● HRMOS採用管理ではUtilでやっていた
■ BirthDateを用意してcalcAgeのようなメソッドを用意してやったほうが良い

87. Entity 例え話
87
■ 同姓同名の人がいたとしてもそれは別人なので、”人”としてはきちんと識
別する必要がある
● case class Human (id: ID, name: Name, gender: Gender)
■ しかし、”名前”というオブジェクトに注目するとただの文字の羅列でしかな
いので、識別する必要はなくValueObjectとして扱えば良い
● case class Name(firstName: String, lastName: String)

88. 88
Entity 例え話
国民を番号で管理するに当たって名前などを仔細に管理する必要はない
性別も名前も年齢もただの記号でしかないとすれば、 ValueObjectで良い
田中太郎くん（１０）
田中太郎くん（１６）

89. 主体によってEntityとValueObjectは変化する
89
たとえばお札（千円札）
一般人にとっては千円札は千円札でしかないので、 ValueObject
日本銀行からすればお札一枚一枚についてキチンと区別して管理する必要があるた
め、お札はEntity（識別子は「記番号」）

90. 一般人にとっての千円

91. 日本銀行にとっての千円 http://www.npb.go.jp/ja/intro/kihon/genzai.html

92. 日本銀行にとっての千円

93. 集約(Aggregate)
93
■ エンティティのライフサイクルを同一にするものを集める集約は最小限に
■ keyword:
● トランザクション整合性
● 結果整合性

94. エンティティのライフサイクル
94
エンティティと値オブジェクトを 集約の中にまとめ、各集約の周囲に境界を定義するこ
と。各集約に対してルートとなるエンティティを１つ選び、境界の内部に存在するオブ
ジェクトへのアクセスは、その ルートを経由して制御 すること。外部のオブジェクトが参
照を保持できるのは、ルートのみとすること。内部のメンバに対する一時的な参照を
渡して良いのは、単一の操作で使用する時だけだ。ルートがアクセスを制御するの
で、内部が知らないうちに変更されることはなくなる。この取り決めにより、どんな状態
変化においても、集約内にあるオブジェクトと集約全体に対して、不変条件をすべて
強制することが現実的になる。
（エリック・エヴァンスのドメイン駆動設計 p.127 第６章 ドメインオブジェクトのライフサ
イクル）

95. 集約
95
トランザクション整合性を保つ必要のあるエンティティたちを１つに 集約する。
集約の境界の外部は結果整合性を用いる。
E.g. 自動車(Entity)はタイヤ(Entity)、車輌(Entity)で構成される。
タイヤと車輌は自動車を構成するものであり、生成～破棄が同一のタイミングで行わ
れるものとすると、自動車(Entity)は 集約のルートエンティティとなる。

96. 集約のルール
96
集約内部のオブジェクトに対してアクセスしてよいのは集約の ルートのみ。
内部を変更したい場合には 必ず集約のルートを通して変更を行う こと。

97. 集約のルール（例）
97
車の速度を上げるのに、タイヤに対して速度を上げるように命令を出すのではなく、車
に対して速度を上げるように命令して、車がタイヤ（エンジン）の回転数を上げるように
する

98. 集約は非常に難しい
98
■ オブジェクトのライフサイクルに対する今までの考え方を捨てて集約につい
て向き合わなければならない
■ トランザクション整合性？結果整合性？
■ 全部含んで巨大な集約できちゃうよ・・・

99. 集約はなぜ難しいのか
99
■ ビジネス的なライフサイクル？
■ システム的なライフサイクル？
■ ドメインモデル？
■ ビューモデル？
■ 頭のなかで概念が交錯する

100. たとえば
100
自動車は車両、タイヤで構成されているが、エンジンも構成物のひとつ
ビジネスの関心事として エンジンは生成から破棄までをキチンと管理したいとすると、
エンジンは自動車の集約の内部にあるべきだろうか？
自動車の生成〜破棄とエンジンの生成〜破棄は果たして同じ ライフサイクルだろう
か？

101. たとえば
101
たとえば、面接と面接評価を考えてみる。
「面接」設定時点では「面接評価」自体は空なので ライフサイクルが違うように思える
が、「面接評価」はそもそも「面接」がないと存在し得ないので「面接」と「面接評価」は
同一の集約であり、「面接」は集約のルートになる

102. 集約の勝手な解釈
102
■ 一つの集約ルート（エンティティ）でどこまで責任を持つかということ
■ モデルの一貫性を保つためのものが集約である
■ （参考）http://masuda220.jugem.jp?day=20091126

103. 5. ドメインモデル貧血症
Domain Driven Design

104. DDDでよく語られるドメインモデル貧血症
104
■ ドメインモデルっぽく出来たものの実際はただのデータを入れる箱でしか無
くドメインモデルがどういった責務を果たすべきなのかが明確になっていな
い（外部に出てしまっている）状態
■ サービス層にばかり処理を書いて、ドメインモデルがほとんどgetterと
setterばかりになってしまっている状態のこと

105. ドメインモデル貧血症に陥らないように
105
■ 常にドメインの役割を意識した実装を心がける
■ パッケージ分けによるサポート

106. パッケージ分けによるサポート
106
■ controller - コントローラー層 Inputの変換を行う
● model - データを受けとるためのモデル
■ presenter - プレゼンター層 Outputへの変換を行う
● model - データを返すためのモデル
■ application - アプリケーション層
● service - 調整役。処理の振り分けを行う。 トランザクション制御 もここ。ドメインロジックは存在しては
ならない。
■ domain - ドメイン層
● model - ドメインモデル。packageで集約をまとめる。ドメインロジックを記
● service - エンティティや値オブジェクトで行うには 不自然なビジネスロジックを記述
■ infrastructure - インフラ層
● repository - 永続化についての責務を負う
■ gateway - ゲートウェイ層。 外部サービスとのやり取りを行う。外部のメールサービスとか
■ util - ユーティリティ

107. 引用 - http://qiita.com/kondei/items/41c28674c1bfd4156186

108. 108
パッケージによる再配置
と
XXServiceにあるメソッドをドメインモデル（あるべき場所）に戻す
既存プロジェクトへの適用

109. DDDを超意訳すると
DDDはドメインモデルを用いて、ソフトウェアの関心事とドメインの関心事をキ
チンと分けて設計しましょうというお話
ちなみに今回のお話の用語は全てDDDのコンテキスト内のお話

110. 110
DDDを理解して実践できているような口ぶりで説明をしてきましたが
まだまだ道半ば

111. 111
DDDを理解して実践できているような口ぶりで説明をしてきましたが
まだまだ道半ば

112. We are hiring!
■ Bizreach: https://bizreach.biz/landing/base_01
■ HRMOS: https://www.hrmos.co/saiyo/
■ Stanby: https://jp.stanby.com/
■ Careertrek: https://careertrek.biz/?trcd=corp
■ Bizreach CAMPUS: https://br-campus.jp/ etc...