実践に向けたドメイン駆動設計のエッセンス

2015年5月27日 増田 亨有限会社システム設計 代表

ギルドワークス株式会社 取締役

はじめに

そんな方々のために、この本の要点（考え方とやり方）を実践経験をまじえて紹介します。

そんな方々のために、この本の要点（考え方とやり方）を実践経験をまじえて紹介します。

・読み解くのが困難・実践でどう活用するか迷っている・やってみたがうまくいかない

実践してみた

• DDD本に出会ってから１０年

•現場で取り組み始めて８年–７つの開発プロジェクト

–３つのコンサルティング

学んだこと

•手ごたえ

•実践の難しさ

•実践していく勘所

実践• 基本に集中して繰り返す–ドメイン駆動設計の基本を理解する

–現場でその基本を繰り返す

–毎日積み重ねる

–１年、2年、3年、…

–チームで取り組む

–複数のチームで取り組む

要点は全部で２８ページ

「まえがき」 ９ページ

１部の導入 ４ページ

２部の導入 ２ページ

３部の導入 ５ページ

４部の導入 ２ページ

「結論」 ６ページ

この２８ページを中心に• 読み解く–わかりにくい言葉を、別の言い方や具体例で–ドメイン駆動設計とそうでないやり方と対比

• 体験談に学ぶ–この本が、エバンス自身の体験談

–私の現場での実践

今日の旅行日程• 「まえがき」 から出発 中核の概念• 第１部の導入 基本用語の説明

– モデル/ドメイン

• 「結論」に飛んで、どこを目指しているかを見学• 「まえがき」に戻って、前提と方向性の確認

– 複雑さという課題– 設計対開発プロセス– 本書の構成– 本書が対象とする読者／ドメイン駆動チーム

• 第１部の導入から、３つの基本活動を理解する– 知識をかみ砕く／言葉を使う／モデルと実装を結びつける

• チームのドメイン駆動設計力を高める体験型の学習• 総合演習とその実践 モデルの成長のさせ方

※ 2部、3部、4部は、「本書の構成」と「体験型学習」で触れます

ドメイン駆動設計の中核の概念

「まえがき」冒頭の３段落 (ページ xii)

ドメイン駆動設計の核心

• ドメインモデリングと設計

• オブジェクトコミュニティでの実践

•設計のイテレーション

• 「進化」を続けるドメインモデル

• チームで体系的に取り組む

中核の概念を読み解く

ドメインモデリングと設計

•不可分

• モデルと設計をいつも関係づける

•同じチームが両方やる

•毎日、モデリングと設計をやる

アンチパターン⇒ モデリングと設計の工程を分ける⇒ 担当者／チームを分ける

オブジェクトコミュニティでの設計とプロセスの良い習慣• エヴァンスが体験してきたこと–オブジェクト指向開発の先駆者たち–彼らの設計や開発プロセスの「良い習慣」

• ドメイン駆動設計を実践する–その「良い習慣」の基本を理解する–「ドメイン駆動」を軸に関係づける–基本に集中して繰り返す–毎日、チームで

オブジェクトコミュニティの良い習慣の参考文献

• ケントベック／マーチンファウラー

ドメイン駆動設計を実践する中で、何度も読み返して参考にしている文献特に「いやな臭い」 「価値」 「原則」が、いつもすばらしいガイド役

オブジェクト指向ではない世界

• 手続き型プログラミング

• 機能分割・工程分割・役割分割

• 技術駆動（計算機駆動）

• 自分たちの体に染みついた世界

• オブジェクト指向の道具を使って、アジャイルを実践しているつもりでも、手続き型から抜け出せていない

実践の勘所⇒ここに気づく⇒抜け出す努力⇒チームで

アンチパターン

設計のイテレーション• ソフトウェアが動いてからもモデリングと設計を続ける–深いモデルの探求

–しなやかな設計の追求

• なぜ？–「結論」に書かれた世界を目指す–そのほうが費用対効果が高い

「進化」を続ける豊かなドメインモデル

• 成功したプロジェクトに共通する特徴

• ドメイン駆動設計の目指すところ

• ８年間やってみて

–どういうことか、ようやくわかってきた

–その威力を実感し始めている

–大きな可能性が見えてきた

チームで体系的に取り組む

• この本を貫く基本の価値観

• チーム

– 「言葉」を使って意図を伝達しあう

– 「言葉」を使う力は、チームの全員が持っている

– この力を磨いてモデリングと設計に活用する

• 体系的

– さまざまな活動の有機的なネットワーク構造

–いったりきたりしながら安定する

–変化を繰り返して成長する

ドメイン駆動設計の核心

• ドメインモデリングと設計

• オブジェクトコミュニティの実践

•設計のイテレーション

• 「進化」するドメインモデル

• チームで体系的に取り組む

基本用語の理解

モデル

ドメイン

第１部ドメインモデルを機能させる

導入文：冒頭の５段落 (ページ 2,3)

モデル•膨大な知識を整理したシンプルでわかりやすい説明

•モデリングのスキル–要約する力

–重要な要素を選び抜く

–厳密に組み立てる

実践の勘所「要約力を磨く」

ドメイン• ソフトウェアウェアを利用する人たちの活動と関心事–ソフトウェアの利用は、活動全体の一部

–関心事の焦点は、ビジネスや業務上の成果

• ドメインではないこと–ソフトウェアを作る活動

– コンピュータの仕組みや挙動

–画面仕様書/機能一覧/ユーザーストーリー/…

ドメインとソフトウェア

利用する人たちの活動と関心事

ソフトウェア

ドメインのモデリング•利用する人たちの「活動」と「関心事」を要約する• 「活動」の要約–アクティビティ図／業務フロー図

• 「関心事」の要約–概念モデル図（クラス図／パッケージ図）

活動の目的／背景

活動の文脈

ソフトウェア

利用する人たちの活動と関心事

活動の文脈のモデリング• 活動の目的や背景の要点を見つける– 「深いモデル」や「コアドメイン」の発見につながる

• 情報源–システム企画書／稟議書–事業計画／企業文化–経済環境／社会情勢

• コンテキスト図–登場人物–関連システム–基本目的の箇条書き

ドメインモデリング• ドメインモデリングは、ソフトウェアの外部の世界を学び理解する活動

• 視野を広げる–使う人たちの活動や関心事へ

–使う人たちの活動の目的や背景へ

•視野を広げるほうが、ドメインの理解が楽になる実践の勘所 ⇒ ドメインをチームで学ぶスキルアップ

基本用語

• モデル–シンプルでわかりやすい説明

–「要約」• ドメイン–ソフトウェアを利用する人たちの活動と関心事–活動には目的や背景がある

ドメイン駆動設計が目指すところ

506ページから511ページ

「結論」から読み解く

「結論」

• 成功とは？

– ドメイン駆動設計は、なにをもって成功なのか

• チームに現れる特徴

– ドメイン駆動設計に真剣に取り組むと何がチームに何がおきるのか

• 学び考える

–優れたソフトウェアを作る中核の活動

• 「深いモデル」 「しなやかな設計」

ドメイン駆動設計の成功

• 何年も成長と変化を続け、価値をつけ加え続ける

–何年にもわたって使われる

–豊富な機能を持つ大きなシステムを段階的に成長させる

–使う喜び、作る喜び。だから続く。

チームに現れる特徴•対象となるドメインを理解し、その理解をソフトウェアに具現化することを「優先」する

• ドメインについて学び続けるその結果、いつまでもモデルの品質には満足できなくなる

技術要素の見方が変わる

プログラミング言語

ドメインを理解しそれをソフトウェアで表現するそこを優先して考えるようになる

フレームワーク 開発ツール プラクティス

パターン

ドメイン駆動設計にどう使うか？どのくらい役に立つか？

クラウド

リファクタリング

学び考える•優れたソフトウエアを作る核心

• ドメインモデルを探求し、それをソフトウエアで表現する活動

• チームで学び考える

• 「言葉」を使う力を磨き活用する

ドメイン駆動設計の実践

深いモデル

しなやかな設計

そこを目指して

チームで学び考える

「まえがき」に戻って

ドメイン駆動設計の前提と方向性

xii から xx ページ

「まえがき」•複雑さという課題

•設計とプロセス

•本書の構成

•本書が対象とする読者

• ドメイン駆動チーム

「複雑さ」• ソフトウェアが複雑になるのは、ソフトウェアを利用する人の行動や関心事が複雑だから–たとえば if文の複雑さの原因–たとえば ひとつの変更がさまざまな画面に影響する原因

• ドメイン駆動設計は、ドメインの複雑さと格闘して、わかりやすいソフトウェア設計をするための考え方とやり方

変更が楽になる実感• 利用する人の活動や関心事を理解し、それをオブジェクトとして表現できると–コード量が減った

–変更箇所が少なくなった

–変更の影響範囲を自信を持って判断できるようになった

–複雑なドメインをすっきり整理して、動くソフトウェアにできた時の快感

「設計とプロセス」• 設計とプロセスは不可分

• ドメイン駆動設計の基本はXP特に以下の２点–設計のイテレーション

–言葉を使った意図の伝達の効果

• ドメイン駆動設計の文脈でXPを学びなおす

XP• 設計重視–毎日、設計に投資する–動いたあとも設計の改善に投資する（リファクタリング）

• 費用対効果–未経験での設計より、経験や事実に基づく設計のほうが費用対効果が大きい– up front 設計が投資効果がある時はやるべき–ドキュメントが投資効果がある時は作るべき

「本書の構成」• 第１部 ドメインモデルを機能させる– ドメイン駆動設計の基本的な目標

• 第２部 モデル駆動設計の構成要素– オブジェクト指向ドメインモデリングの基本

• 第３部 より深い洞察に向かうリファクタリング–役に立つ実用的なモデルを見つける原則とテクニック

• 第４部 戦略的設計–第１部で示した目標をより大きな規模で実現する

第１部ドメインモデルを機能させる

• ドメイン駆動設計の基本的な目標

• 第１部（１章、２章、３章）の理解が第２部以降の前提

• ここの理解とスキルアップが実践の勘所– １章 知識をかみ砕く

– ２章 コミュニケーションと言語の使い方

– ３章 モデルと実装を結びつける

• 体験しながら学ぶ– 知識をかみくだき蒸留する

– 言葉を使った意図の伝達／モデルと設計のテスト

– モデルをコードで表現する

第２部モデル駆動設計の構成要素

• オブジェクト指向ドメインモデリング

–初心者には難しい

–チームでドメイン駆動設計を実践するには、初心者向けのスキルアップの工夫が必要

• 体験しながら学ぶ

–誰でもすぐ実践できるオブジェクト指向の基本

–現場で使えるドメインモデリングの基本

第３部より深い洞察に向かうリファクタリング

• 役に立つ実用的なモデルを見つけるには、この実践が必須

–暗黙的な概念を明示する

– しなやかに設計し、実験と変更を繰り返す

• 内容がわかりにくい

• 体験しながら学ぶ

– 「ドメイン駆動設計」の視点で「リファクタリング」をやってみる

第４部戦略的設計

• 第１部の内容の理解が大前提

– 「知識のかみ砕き」を大規模に実践する

– 「言葉を使った意図の伝達」を大規模に実践する

– 「モデルと実装の結びつけ」を大規模に実践する

• 体験しながら学ぶことはむずかしい領域

– ビッグローブの開発部門の主要メンバーが集まってやった「コンテキストマッピング」は、貴重な体験になっている／ドメイン駆動チームの今後が楽しみ

「対象とする読者」• 「中級」のオブジェクト指向ソフトウェアの開発者

• オブジェクトモデリングの「若干」の知識

• この前提は、ハードルが高い

–目の前の現実「手続き型」の「プログラミング」経験者

現実から出発する• 手続き型から抜け出せていない

• オブジェクト指向設計のスキルと経験の不足

• オブジェクトモデリングの知識と経験の不足

• ドメイン駆動設計を実践するために、チームでこの現実を変えていく

• オブジェクト指向のモデリングと設計の基本スキルを、チームで体験しながら学んでいく

「ドメイン駆動チーム」• ドメイン駆動設計はチームで実践する時に最大の収穫を得る

• チームで、ドメインモデリングと設計の基本を学び、スキルを磨いていく

• 言葉を使う能力を磨き、モデリングと設計に活用する

ドメイン駆動設計• ドメインがもつ複雑さに挑戦する

• イテレーティブな活動

• オブジェクトモデリングの実践

• オブジェクト指向ソフトウェア開発の実践

• チームで「言葉」を使う活動

第１部ドメインモデルを機能させるから読み解く

ドメイン駆動設計３つの基本活動

モデルを中心にした活動

• １章のテーマ

–モデルを生みだす活動

• ２章のテーマ

–モデルを改善する活動

• ３章のテーマ

–モデルと設計と結びつける活動

モデルを活用する

第２章言葉を使った意図の伝達

第１章（ドメインの）知識をかみ砕く

第３章モデルと実装を結びつける

モデルドメインの知識をかみ砕き、蒸留してわかりやすく説明する

要約されたドメインの知識を実装に反映する

言葉を使ってモデルを改善する

会話の基本語彙を提供する

実践の土台づくり体験しながら学ぶ

実践の土台づくり• ソフトウェアを使う人たちの活動と関心事を学ぶスキル

•学んだ知識を要約するスキル

• モデルの改善に「言葉」を使うスキル

• モデルと実装を結びつけるスキル

体験しながら学ぶ

• 現場で、実際の案件で– OJT

–もっとも効果的

–ただし障害だらけ

• 実際のチームで、現場からちょっと離れて–現実の案件をテーマに

–納期、費用、過去の習慣の縛りをはずして

• 架空のチームで、架空の案件で–疑似体験

チームで学ぶ体験型学習講座お品書き

• ドメイン駆動力– 利用する人たちの活動と関心事を学ぶスキル

– ドメインモデリングの「ひきだし」を増やす

• モデル駆動力– 要約するスキル

• 長い文章から要点を選び出す

• 要点を視覚化しながら整理する

• 設計力– モデルと実装を結びつけるスキル

• リファクタリング ドメイン駆動設計版

ドメイン駆動力

第１章 知識をかみ砕く

活動と関心事を学ぶスキルドメインモデリングの引出を増やす

ソフトウェアを利用する人たちの活動と関心事を学ぶスキル

学習パターン慶応義塾大学 湘南藤沢キャンパス 井庭研究室

ドメインを学ぶコツをつかむ

• まずはつかる

• 量は質を生む

• 言語のシャワー

• 話すことでわかる

• 広げながら掘り下げる

• 鳥の眼と虫の目…

学習パターンの使い方を学ぶ

• 各自、読んでみる–ホームページ

–小冊子（PDF)

• 学習パターンを参考にチームで話し合う– ドメインを学ぶために不足していること

– ドメインを学ぶための行動計画

• 「ドメインエキスパート」への期待ではなく、自分たちが起こす行動に焦点をあてる

ドメインモデリングの「ひきだし」を増やす

オブジェクトモデリングの基本部品

• Entity/Value Object/Service の３分類は、抽象的すぎる

• もうすこし具体的に、業務やビジネスのドメインのモデリングする時の「部品」を覚えるほうが、わかりやすい

• 「部品」– 「完成品」ではなく「出発点」

– 「浅い」モデルをさくっと作るための道具

– ここから「豊か」で「深い」モデルを探求していく

関心事の基本部品

• ５種類の対象ヒト・モノ・コト 時・場所– どう 「識別」 しているか

– どう 「説明」 しているか

– どう 「関係」 しているか

• 具体的に例をあげて話あってみる

• 「豊かな」モデル、「深い」モデルへの手掛りを見つける練習– ５種類の任意の２つの組み合わせ（２０パターン）の「関係」について、具体例をどんどんあげてみる

よくでてくる関心事

• 「識別」と「説明」

• 「記録」と「通知」

• 「勘定」 （履歴と状態）

• 「約束」と「期日」 （将来の「コト」の約束）

• 「契約」と「計画」 （履行責任）

• 「照合」と「消込」

• 「分類」と「方針」 （区分とビジネスルール）

• 「横顔」と「選好」と「所見」 （個性と判断）

よくでてくる関心事の学び方

• みんなが先生役になって発表しあう（教えることによる学び）

–パターンを説明する

–具体例をあげる

• 参考文献

データモデリング系も参考にしている

モデル駆動力

文章を要約する力図を使って要点を整理する力

「要約」するスキル

第１章 知識をかみ砕く第２章 コミュニケーションと言語の使い方

長い文章から要点を選び抜くスキル

• 題材

– ドメイン駆動設計の要点２８ページ

• 段落を40字に「要約」してみる（各自）

• お互いの「要約」を比べる

–同じところ／違うところ

– 「要約」の意図や迷った過程を説明する

• よりしっくりくる「要約」を声に出して作ってみる

• 書いて読んだ時にしっくりくるか確認する

要点を図を使って整理するスキル

• 題材– 実際の案件– ７章の貨物輸送システム

• 手法– リレーションシップ駆動要件定義(RDRA)– 目的や背景を整理⇒価値モデル（コンテキスト図）– 「活動」を要約⇒業務モデル（アクティビティ図）– 「関心事」を要約⇒概念モデル（クラス図）

• 狙い– チームで、ドメインモデリングの基礎を習得する

リレーションシップ駆動要件定義参考文献

• 神崎善司さん

• 要件定義の実践手法

• システムを取り巻く環境（=ドメイン）を理解し、システムと関係づけることを重視した手法

活動の目的／背景

システムを取りまく環境

ソフトウェア

利用する人たちの活動と関心事

ドメインモデリング演習

• 一枚のメモ書き （システム企画書のドラフト）

• ２時間 さくっとドメインモデリング– メモを読む– 目的を要約する ⇒ コンテキスト図を描く– 利用者の活動を要約する ⇒ アクティビティ図を描く– 利用者の関心事を要約する ⇒ 概念クラス図を描く– メモ／コンテキスト図／アクティビティ図／概念クラス図を整合させる

• ２時間 モデルの改良– お互いのモデルを説明しあう– 違いを話あう （言葉にする／耳を傾ける／矛盾を見つける）– 話し合った内容の気づきを、自分のモデルに反映する

設計力

「リファクタリング」のドメイン駆動設計版

モデルと実装を結びつけるスキル

第３章 モデルと実装を結びつける第４章 ドメインを隔離する第９章 暗黙的な概念を明示的にする第10章 しやなかな設計第16章 大規模な構造

設計力をあげる

• ドメイン駆動設計に必要な設計力

–第１０章 しやなかな設計

• 意図の明白なインタフェース （手段の隠ぺい）

• 概念の輪郭と一致させる

• 独立性を高める （組み立て型の柔軟性）

• ドメイン駆動設計のいやな臭いと処方箋• 意図がはっきりしないメソッド／クラス／パッケージ

• 利用する人たちの関心事（概念）と一致しないコード

• 複雑に絡み合ったクラス／パッケージ

大きなリファクタリング

しなやかな設計のスキルリファクタリング ドメイン駆動設計版

レイヤ構造

ドメイン層の構造化

良い部品

いやな臭い

処方箋

ドメイン駆動設計の文脈でコードのいやな臭い探しと改善体験

• 重複したコード• 長すぎるメソッド• 巨大なクラス• 長すぎるパラメータリスト• データの群れ• 基本データ型への執着• スイッチ文• コメント• 疑わしき一般化• メッセージの連鎖（メソッドチェーン）• データクラス• プレゼンテーション層へのビジネスロジックの分散• データソース層へのビジネスロジックの分散• ．．．

ドメイン駆動設計として何が問題か？

オブジェクト指向に頭を切り替える

• 「手続き型コード」の発見と修正を体験する

–既存のコードを調べる

–手続き型からオブジェクト指向に書き換えられそうな箇所を発見する⇒ 次の「良い部品」参照

–実際に書きなおしてみる

良い部品

• 意味のある単位にコードを分ける– 段落に分ける

– メソッドの抽出

– クラスの抽出

– パッケージの導入

• 利用者の関心事を「名前」で説明する– 説明用の変数

– 説明用のメソッド

– 説明用のクラス

– 説明用のパッケージ

良い部品

• Value Object– ドメインに特化したString

• PersonName, MailAddress, Telephone, …

– ドメインに特化したInteger/Decimal• Money, Quantity, Rate, …

– ドメインに特化したLocalDate• DueDate, ExpireDate, DateOfBirth

• ファーストクラスコレクション– 一覧、履歴、グループ

• Products, Members, PurchaseHistory, …

– 利用者の関心事をクラスで明示する

ループ処理の隠ぺい

データ操作の隠ぺい

良い部品 （分岐の表現）

• ガード節– if/else を 早期リターンを使って分解する

– 複文を複数の単文に ⇒ 独立した部品

• １箇所だけの分岐構造– 同じ分岐構造を複数個所に書かない

• 多態– State/Strategy パターンで、分岐ごとのロジックを別オブジェクトに

– Enum（列挙） で、区分の構造を宣言的に

– Enum（列挙） で、区分に振る舞いを持たせる

ドメイン駆動設計大きなリファクタリング

手続き型のアーキテクチャ

プレゼンテーション層

ビジネスロジック層

データソース層

データの受け渡し

連想配列/DTO/貧血ドメインモデル

データの受け渡し

連想配列/DTO/貧血ドメインモデル

オブジェクト指向のアーキテクチャ

プレゼンテーション層

サービス層データソース層

ドメインモデル

三層＋ドメインモデル

依頼する（任せる）

ドメインオブジェクトを渡す

ドメインオブジェクトを渡す

オブジェクトとデータモデルの変換装置

オブジェクトとHTTPリクエスト／レスポンスの変換装置 参照する 参照する

実装技術

• Spring Boot

– フレームワーク自体が三層＋ドメインモデル指向• @Controller/@Service/@Repository

– サンプルが三層＋ドメインモデルになっている

• プレゼンテーション層

– Spring MVC HTTPとドメインモデルの変換技術

– Thymeleaf HTMLを尊重したビュー技術

• データソース層

– myBatis SQLを尊重したオブジェクトマッピング

三層＋ドメインモデル設計の改善

• ドメインモデルに、利用者の関心事を集中する– 豊かなモデル ／ 深いモデル への道筋

• いやな臭いとリファクタリング– プレゼンテーション層にまぎれこんだドメインロジック

• 新着アイコンをつけてわかりやすく ⇒ ドメインの関心事

• ビューに if(新着) を書かない工夫

– データソース層やSQLにまぎれこんだドメインロジック• 動的にSQL組み立てない工夫

– 多態を使った検索の切り替え

• WHERE句やORDER BYの意図をドメインオブジェクトで表現– SQLに渡すパラメータオブジェクトの設計改善

大きなリファクタリングドメインモデルの構造の改善

• コードを読んでもはっきりしない問題– パッケージの名前– パッケージの階層構造（ファイルシステム上）– パッケージの依存関係（パッケージ図）

• 改善の必要性を発見する– わかりにくさを感じたら

• 声に出してモデリングしてみる• 絵にしてみる （特に依存関係）

• 改善の手段– 名前の変更– パッケージの分割／統合／追加– クラスの移動による依存性の単純化– クラスの分割＋クラスの移動による依存性の単純化– 業務の時系列とパッケージの依存関係の突き合わせ

総合演習第７章 言語の使用 から

モデルの成長のさせ方その実践

第７章のモデルの成長過程

必要な概念がそれなりに形になったモデル

システムの概要説明

基本機能（シナリオ）

ｴﾝﾃｨﾃｨと値ｵﾌﾞｼﾞｪｸﾄを区別する

「関連」を設計する

「集約の境界」を設計する

「リポジトリ」を選択する

「シナリオ」をウォークスルーする

オブジェクトの「生成」

立ち止まって「リファクタリング」

「モジュール」の設計

「拡張」 外部接続・モデルの強化・性能

価値モデリング活動モデリング関心事モデリングそのイテレーション

初期のモデリング

初期のモデリング

この総合演習の参加資格

• 中級のオブジェクト指向ソフトウェア開発者

• ドメインモデリングの「若干」の知識

• 「ドメイン駆動設計」の第１部と第２部の理解

• ハードルは高い

• 体験しながら学んでいる

• 少しずつ成長ができている手ごたえ

ドメイン駆動設計の実践

目指すところ• 何年も変化と成長を続けるソフトウェア

• 価値を加え続けるソフトウェア

そのために

• 利用者の活動や関心事を理解し、それをコードで表現することを「優先」する

• 学び考える

• 深いモデル／しなやかな設計

モデリングと設計• 不可分• オブジェクト指向• 声に出してモデリングする• 言葉に耳を傾ける• ぎこちなさを精査する• 矛盾について熟考する• 文献を読む

ドメイン駆動設計を実践する

•毎日やる

• １年2年と続ける

• チームで実践する

•複数のチームで実践する

•体験しながら学び成長を続ける