Sansan DDD勉強会 #2の発表資料です。

1. 株式会社ネクストスケープ 御中
青木 淳夫 ＆ 上坂 貴志
Sansan DDD勉強会 #2
http://connpass.com/event/23174/
2015.12.16
「実践ドメイン駆動設計」社内読書会まとめ
～IDDD本難民に捧げる1章から7章～

2. 2
本日は、翔泳社さんの書籍「実践ドメイン駆動設
計（通称IDDD本）」の社内読書会の状況と、書籍の
ポイントを整理して紹介します。
IDDD本は、DDDを解説した書籍の中ではとても読みや
すく、実際に活用してみようと思わせる内容となっていま
す。とはいえ、520ページ（付録除く）もあるため、個人
で読み進めることは容易ではありません。そこで、ネクス
トスケープ社では、週に一度、読書会を行っています。
今回は、この読書会の様子と、IDDD本の章別の要約と
ポイントをまとめて紹介します。
紹介する内容が、これからIDDD本を読んでみようと思
われる方の道標になれば幸いです。
※このスライドに書いている内容は、独自の理解・見解によるものです。
DDDのとらえ方も人それぞれですし、何かありましたら、懇親会等で心優し
くご指摘いただけると幸いです。
このセッションでお伝えしたいこと

3. 3
大手SIer、テクニカルライター、福井のWebデザイン会社を
経て、ネクストスケープ所属。
プログラマーとしてシステム開発の難しさを感じていた2000
年頃、XPとvbUnitに出会い、アジャイルに傾倒。
その後、Javaでの大規模ウォーターフォール案件でチームリ
ーダーを経験したり、Web制作会社でPHPを書いてみたり。
最近はデジタルマーケティングやクラウドソリューションに
携わったりすることが多い。
Microsoft MVP for Visual Studio(2006～)
Sitecore MVP(2012～)、Certified Scrum Master。
.NET関連の著書3冊。
Microsoft技術とOSSが好き。
散歩とラーメンとお酒と甘いものも好き。
青木 淳夫(@aoki1210)
自己紹介
上坂 貴志(@takashiuesaka)
長年に渡ったフリーエンジニア稼業に終止符を打ち、ネク
ストスケープ所属。エバンジェリスト・アーキテクト。
若かりし保守・運用に苦しんでいた時期にXP・TDDと出会
い、実プロジェクトで何度も実験。そして失敗。
同時期にソフトウェアアーキテクチャの重要性を痛感して
修行を開始。様々なプロジェクトでTry＆Errorを繰り返し
てきた。
近年はMicrosoft Azureとの関わりが多く、エバンジェリス
トという仕事柄、登壇・執筆活動がメイン。
Microsoft MVP for Azure、Certified Scrum Master。
Azure Machine Learingの共著1冊。
Microsoft技術とアーキテクチャ、DDD、Scrumが好き。
温泉とタイ料理が好き。甘いのも辛いのどっちも好き。

4. 4
 １週間で１回開催（ときおり非開催）
 1回で0.5章を目安
 5月から実施
 参加者は社員もパートナーさんも含め3名から10名くらい（若手多め）
 固定メンバは5名程度
 現在10章まで完了
週に1回のランチ勉強会
読書会の様子

5. 5
読書会を始めたきっかけは「IDDD本の中身を皆でディスカッションして、お互いの理解を深めたい」という意図でし
た。読書会という名目ですが、若いエンジニアが多いので、開発の課題やアーキテクチャそのものの基礎的な説明が多
くなっているため、時間内訳の95％ほど上坂さんがDDDの話を熱く語る時間になっています。
現在の1周目が終わったら、改めてワンランク上の２周目を行う予定です。
読書会の背景と現状

6. 6
社内でのDDD実践例（勤怠管理アプリケーション）
ピットタッチで登録した勤務情報を編集したり登録管理するアプリケーションをDDDで構築しました。
（使用技術→CentOS / C#, ASP.NET MVC, Azure, SQL Database, Azure Table / Power BI 等）
上坂さん曰く、過去数回にわたって、C#でDDDを行ったが簡単ではなかったとのこと。
この例ではDDDでそれなりに上手くいったそうです。

7. 株式会社ネクストスケープ 御中
目次：IDDD本の構成

8. 8
目次の章で挫折して難民になりかねないので、興味ある章から読んでも良いかもしれません。
IDDD本の目次
章 タイトル ページ コメント
目次 序文、賛辞、初めに、謝辞、著者、訳者、本書の読み方 24 各章の概要説明があります
1章 DDDへの誘い 38 DDDを実践するメリットについて
2章 ドメイン、サブドメイン、境界づけられたコンテキスト 40 巨大な泥団子にならによう業務別に分けよう
3章 コンテキストマップ 24 迷子にならないためのもの
4章 アーキテクチャ 53 レイヤから、ヘキサゴナルアーキテクチャへ
5章 エンティティ 45 値オブジェクトとの違いを意識
6章 値オブジェクト 42 エンティティとの違いを意識
7章 サービス 19 変換・算出はここで
8章 ドメインイベント 45 分散＆同期のテクニック
9章 モジュール 11 「内部構成もユビキタス」で可読性アップ
10章 集約 40 コンテキスト内の最小トランザクション単位
11章 ファクトリ 11 ファクトリって、Factoryメソッドじゃないんだよ
12章 リポジトリ 44 いわゆるリポジトリ
13章 境界づけられたコンテキストの統合 56
14章 アプリケーション 28
付録A 集約とイベントソーシング：A+ES 41
付録B 参考文献 7

9. 9
IDDD本を読んでみよう
技術書は、最低3回読むと
著者が伝えたいことを、よく理解できますよ
500ページもあるIDDD本を3回も読むとか、
そんなことできるんですか…？
IDDD本の目的と構成を理解すれば、
そんなに難しくないですよ！

10. 10
IDDD本の目的は「DDDの理論を実際に適用する」ことで、それらを順序だてて説明しています。
また、SaasOvation(サーズオベイション)という疑似プロジェクトを例としたサンプルコードも提
供されています。
IDDD本の構成
主題：実践ドメイン駆動設計
副題(目的)：エリック・エヴァンスが確立した理論を実際の設計に応用する
著者：ヴァーン・ヴァーノン ／ 訳者：高木正弘
実現したい
未来
DDDを達成する
ための分類
1章
DDDへの誘い
2章
ドメイン
3章
コンテキスト
設計・モデリング
・実装方法
4章
アーキテクチャ
5章
エンティティ
6章
値オブジェクト
7章
サービス
8章
ﾄﾞﾒｲﾝｲﾍﾞﾝﾄ
9章
モジュール
10章
集約
11章
ファクトリ
12章
リポジトリ
13章
ｺﾝﾃｷｽﾄ統合
14章
ｱﾌﾟﾘｹｰｼｮﾝ

11. 11
DDD実装サンプル
IDDD本のソースコードサンプルの場所
IDDD本SaasOvation - Javaのサンプル（ヴァーンさん）
https://github.com/VaughnVernon/IDDD_Samples
IDDD本SaasOvation - C#のサンプル（ヴァーンさん）
https://github.com/VaughnVernon/IDDD_Samples_NET
おまけ ASP.NET MVC + C# ミュージックストアのDDD版
https://github.com/thiagolunardi/MvcMusicStoreDDD
さらにおまけ、IDDD本 C#のサンプルの日本語に適当にいじったもの
https://github.com/aoki1210/IDDD_Samples_NET

12. 株式会社ネクストスケープ 御中
１章：DDDへの誘い

13. 13
1章の構成は
• 私にもできるの？
• あなたがDDDをすべき理由
• DDDを行う方法
• DDDを採用する事業価値
• DDDの導入にあたっての課題
• 現実味のあるフィクション
となっています。
DDD（ドメイン駆動開発）を使うとどんなメリットがあるのか、なぜDDD以外のや
り方だと失敗するのか、そして、上司、ドメインエキスパート、技術者へのDDDのす
ばらしさの売り込み方法を紹介しています。
「1章：DDDへの誘い」の構成

14. 14
DDDに取り組める人は、若手の開発者、中堅レベルの開発者、ベテラン開発者、アーキテ
クト、ドメインエキスパート、マネージャ等。学ぶことができる人であれば、だれでも
DDDを実践できる。
DDDのメリットは次の3つ。
1. ドメインエキスパートと開発者は、共同で業務をモデリングし「ユビキタス言語」を確立し、「私たち
とあの人たち」ではなく「私たち」のチームを作る。
2. 事業戦略構想に対応するため、サービス指向アーキテクチャやビジネス思考アーキテクチャを実現できる。
3. ソフトウェアの真の技術的要求を満たす。スケーラブルで、SLAを満たし、アーキテクチャから詳細設計まで様々
な問題に対応できる。
逆に複雑なシステムでDDDを使わないと、シンプルに作ることができず開発に失敗する可
能性もあります。
「1章：DDDへの誘い」のポイント

15. 15
DDDとユビキタス言語は実現できる
お客さんも、ドメインエキスパートも、開発者も、
あらゆるところで同じ言葉「ユビキタス言語」で
意思疎通できたら最高だと思いませんか？
理想はわかるんですが、
昔から存在するUML（統一モデリング言語）ですら
エンジニア以外には普及していないのに、
DDDの導入って難しいんじゃないですか..
これまでは技術的なシステム都合（特にDBと永続化）に引きずられて、
業務とシステムの間にギャップが生じていたんです。
これから、DDDはもっと普及すると考えています。

16. 株式会社ネクストスケープ 御中
2章：ドメイン、サブドメイン、
境界づけられたコンテキスト

17. 17
2章の構成は
• 全体像
• なぜそれほどまでに戦略的設計を重視する
のか
• 実世界におけるドメインとサブドメイン
• 境界づけられたコンテキストの意味を知る
• サンプルのコンテキスト
となっています。
ここではDDD固有の主要概念である「ドメイン」「
コアドメイン」「サブドメイン」「境界づけられたコ
ンテキスト」の説明が行われています。
「2章：ドメイン、サブドメイン、境界づけられたコンテキスト」の構成
※ドメインの構成を示した図
コアドメイン
支援サブドメイン
汎用サブドメイン
コンテキスト

18. 18
技術による戦術的パターンに走らずに、戦略的設計（ドメインとコンテクストに注目
し、適切に分けよう）を実践しようという内容です。
ドメインとは、問題空間（問題領域）のこと。
業務そのものでアクターのアクションなども含まれる。
ビジネス上最も重要なもの、戦略的に不可欠なものをコアドメインと呼び、それらを
補助する支援サブドメイン(業務的)と汎用サブドメイン（非業務的）が存在する。
例えば、「受注」「在庫」などは、同じ言葉で話していても、ドメイン毎に意味合い
が違うことがあるので注意が必要。
境界づけられたコンテキストとは、解決空間（解決領域）のこと。
言語的な境界を意識し、全部入りの巨大なモデルを作らないようにする。
ドメインエキスパートの声を聴いて、境界づけられたコンテキストを構築する。
例えば、「認証アクセスコンテキスト」「在庫コンテキスト」など、大きすぎても小
さすぎてもいけない。
「2章：ドメイン、サブドメイン、境界づけられたコンテキスト」のポイント

19. 19
複雑なシステムを作らないために、ユビキタス言語の呼び方に敏感になろう
あたりまえですが、複雑でないシンプルなシステムを作りたいですね。
しかし、システムを分割しても、
ひとつのDBでデータを管理してしまったことで
分割した意味が無くなってしまったことはありませんか？
それは、ありますね。
システムや業務が違うのに、
DB変更時に調整が必要なケースですよね。
そうなんです。DBをひとつだけで管理すると
オブジェクトもひとつしか意味を持てず、巨大な泥団子になりかねません。
システムや業務が変わったら作業者も異なることが多いので
ユビキタス言語の境界を意識して
正しいコンテキストで分割したいですね。

20. 株式会社ネクストスケープ 御中
3章：コンテキストマップ

21. 21
3章の構成は
• なぜそんなにもコンテキストマップは重要なのか
です。
2章のドメイン、コンテキストの境界を理解することができ、モデルの統合に役立ち
ます。
「3章：コンテキストマップ」の構成
コンテキストマップ

22. 22
コンテキストマップは、プロジェクトの現状を表す図（アーキテクチャドキュメ
ント）のこと。目的は解決空間（解決領域）の現状を俯瞰できるようにすること。
DDD固有の図で、コンテキストを丸で囲む。
コンテキスト間の関係を上流（Upstream）と下流(Downstream)で示す。
例えば基盤チームは上流。それを利用する業務チームは下流となる。
チームの力関係がアーキテクチャに影響を与えてしまうこともあるが、
パートナーシップで協力的な関係（顧客／供給者の関係）を築くことが望ましい。
残念ながら下流のチームが順応者の関係になってしまうことも多い。
コンテキスト間が蜜に依存しあわないように、
上流と下流のコンテキストの間に腐敗防止層を作ることが多い。
なお、あらゆるコンテキストから依存されるような共有カーネルは
各チームで相談しないといけないので、やめるべき。
「3章：コンテキストマップ」のポイント

23. 23
ドメインとコンテキストの最新状況を「見える化」しよう
ドメインと境界づけられたコンテキストを設計したら
コンテキストマップを作りましょう
プログラムの依存関係に似ているから
納品時にツールで自動生成とかじゃダメですかね..
開発の途中で、コンテキストの状態が分からなくなって
混乱してしまうことがあるんです。
目立つところに書いておいて、
共通認識と正しい理想を描けるようにしましょう。

24. 株式会社ネクストスケープ 御中
4章：アーキテクチャ

25. 25
4章の構成は
• CIOへのインタビュー
• レイヤ
• ヘキサゴナル（ポートとアダプター）アーキテクチャ
• サービス指向
• Representational State Transfer（REST）
• コマンドクエリ責務分離（CQRS）
• イベント駆動アーキテクチャ
• データファブリック及びグリッドベース分散コンピューティング
となっています。
ここでは、さまざまなアーキテクチャでDDDを実現する方法を検討しています。
「4章：アーキテクチャ」の構成
①レイヤ
アーキテクチャ
③ヘキサゴナルアーキテクチャ
（hexagonalは英語で6角形の意味）
②レイヤ
アーキテクチャ(DI使用時)

26. 26
エバンズ本ではレイヤアーキテクチャを中心に説明されていますが、
これに対してIDDD本では、ドメインの独立性を保つものとして、
ヘキサゴナルアーキテクチャ（ポート＆アダプタ）を提唱しています。
レイヤアーキテクチャでは責務を「UI層」「 アプリケーション層」「ドメイン層」「イン
フラストラクチャ層」の分類でしたが、ヘキサゴナルアーキテクチャは、入力元、出力先
に依存しないインターフェイスで切り替えられるようになっています。
DDDのアーキテクチャでは、複数のドメインで連携する場合には分散システム的な挙動と
なるため、分散アーキテクチャが主流です。その例として以下のようなパターンが挙げら
れています。
・コマンドクエリ責務分離（CQRS）
・イベント駆動アーキテクチャ
・パイプ＆フィルター
・イベントソーシング
サービス指向技術（SOA/マイクロサービス等）との関連性も高いので、クラウドデザイン
パターンを理解することもお勧めです。
「4章：アーキテクチャ」のポイント

27. 27
ヘキサゴナルアーキテクチャのメリットって何
DDDでは、ドメイン層が
他のレイヤに依存したり汚染されたりしないようにします
なじみ深いレイヤーアーキテクチャと
DIじゃ駄目なんですか？
DIを用いればレイヤ間の依存は分離できるんですが、
アプリケーション層やインフラストラクチャ層が肥大化しやすいんです。
ヘキサゴナルアーキテクチャにすることで
ドメイン層以外が綺麗になるメリットがあります。

28. 株式会社ネクストスケープ 御中
5章：エンティティ

29. 29
5章の構成は
• なぜエンティティを使うのか
• 一意な識別子
• エンティティおよびその特性の発見
となっています。
右図の例では、Personクラス・
Userクラスが「エンティティ」、
TenantIDクラスが「識別子」
となっています。
「5章：エンティティ」の構成
※Entityの例
(IDDD本 C#サンプルソースより)

30. 30
エンティティは、状態が変化していくオブジェクトです。
オブジェクトの「生成・変更・破棄」までを管理する必要があるため、
一意性が必要になり、それぞれのオブジェクトが一意な識別子を持ちます。
RDBの識別子はオートナンバーやシーケンスといったDB問い合わせによる数値型のIDが
主流ですが、DDDではインスタンス生成時にアプリケーション側で識別子を生成します。
一意な値は、128Bitから32バイトの文字列の型（UUIDやGUID）を使用します。
エンティティのバリデーションを行う実装として、Entityクラスの責務ではなく、
Validationクラスの責務になる例を紹介しています。
（この章は、OOPのプラクティス的な話が詰まった章です。）
「5章：エンティティ」のポイント

31. 31
DDDが表すエンティティとは
あらためてですが、DDDの
エンティティってなんだと思います？
エンティティといえばER図ですよね。
だったら、テーブル構造とかレコードですかね..？
RDBなら、それでも間違いではないんですが、
DDDのエンティティは
「ライフサイクルを管理するオブジェクト」を表します。
ライフサイクルを管理する必要があるため、
一意で不変の識別子を持ちます。

32. 株式会社ネクストスケープ 御中
6章：値オブジェクト

33. 33
6章の構成は
• 値の特徴
• ミニマリズムを考慮した結合
• 標準型を値として表現する
• 値オブジェクトのテスト
• 実装
• 値オブジェクトの永続化
となっています。
モデルから値オブジェクトの特性を
見つけ出す方法について紹介されています。
「6章：値オブジェクト」の構成
※値オブジェクトの例
(IDDD本 C#サンプルソースより)
この図では、前述のPersonエンティティが、
値オブジェクトであるContactInformation
クラスをプロパティに持ちます。
さらに、 ContactInformationクラスが値オ
ブジェクトであるEmailAddressクラス、
Telephoneクラス、PostalAdressクラスをプ
ロパティに持っています。

34. 34
値オブジェクトは「ドメイン内の何かを計測したり、定量化したり、説明したり」するも
のです。
例）電話番号を数値型（Int型）ではなくTelephone型を使うことで、ドメインの業務を示
すことができます。
値オブジェクトは「不変」が望ましいとされています。
（エンティティは「状態が変化していくオブジェクト」のため逆ともいえます。）
不変ということは、コンストラクタ呼び出し時だけ値を設定可能です。Getterはあります
がSetterはありません。変更時にはオブジェクトそのものを差し替えます。
不変であれば責務がシンプルになり、利用する側としても影響範囲が分かりやすく、バグ
が入りにくくなるメリットがあります。
永続化の実装方法としては、非正規化するか、もしくは正規化した専用テーブルを使う場
合があります。最近の人気はNoSQLです。
「6章：値オブジェクト」のポイント

35. 35
値オブジェクトこそDDD
DDDで一番重要なのは
「値オブジェクト」かもしれないですね。
え、そうなんですか？
「値オブジェクト」ってDTO(DataTransferObject)みたいな
シンプルなクラスっぽいので、簡単かと思っていました。
DDDでは「電話番号」のようなユビキタス言語を
プリミティブな数値型で済ませてしまうのではなく
「値オブジェクト」として表現します。
そのため業務を理解し、責務を検討し、
「オブジェクトの振る舞い（プロパティとメソッド）」を設計する必要があります。
これはオブジェクト指向のモデリングスキルが必要ともいえます。

36. 株式会社ネクストスケープ 御中
7章：サービス

37. 37
7章の構成は
• ドメインサービスとは何か（…の前にドメインサービスとは何でないのか）
• 本当にサービスが必要なのかをたしかめる
• ドメインにおけるサービスのモデリング
• サービスのテスト
となっています。
「7章：サービス」の構成
※ドメインサービスの例
(IDDD本 C#サンプルソースより)
※アプリケーションサービスの例
(IDDD本 C#サンプルソースより)

38. 38
ドメインモデルの設計をしていると、エンティティや値オブジェクトといった「ドメインオ
ブジェクト」だけではなく、外に出したほうが良いロジックも存在します。その際、ステー
トレスなクラス「サービス」を使用できます。
大きく、サービスは次の２つが存在します。
・ドメインサービス
エンティティや値オブジェクトの責務ではないドメインモデルのロジック
（ドメインオブジェクトを使う処理やファサード）
・アプリケーションサービス（詳細は14章）
非常に薄く、ドメインモデル上のタスクの調整のために使うロジック
（腐敗防止層の変換・アダプタ等）
サービスを作るときにミニレイヤのアンチパターンにならないよう注意する必要があります
（エンティティや値オブジェクトがデータコンテナに成り下がらないように注意します）。
「7章：サービス」のポイント

39. 39
サービスは注意しないとDDDが失敗する
エンティティと値オブジェクトに記述することが
適切ではないビジネスロジックは
「サービス」に書いてもいいですよ
了解しました。
では、ドメインモデルのロジックは
すべて「サービス」に実装しますね。
あなたのような人が
「ドメインモデル貧血症」「トランザクションスクリプト」
だらけのメンテナンスしにくいコードを書くんですよ..
適切なエンティティと値オブジェクトにロジックを書いて、
「サービス」の利用は極力控えてくださいね。

40. 40
■神原さんのスライド「Implementing Domain-Driven Design: Part 1」
http://www.slideshare.net/atsushikambara/implementing-domaindriven-design-part-1
■DDD本
http://www.amazon.co.jp/dp/4798121967
■ IDDD本
http://www.amazon.co.jp/dp/479813161X
■クラウドデザインパターン
http://www.amazon.co.jp/dp/4822277372/
■ Azureクラウドデザインパターン
http://www.amazon.co.jp/dp/4822298337/
■ Developing Core Business Applications with Domain-Driven Design (DDD) and Microsoft .NET
https://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/DEV-B311
参考文献

41. ご清聴ありがとうございました。
DDDで良いシステム開発を！