はじめに

本書は、ドメイン駆動設計（Domain-Driven Design, DDD） のエッセンスを、誰もが知っている昔話「桃太郎」を題材にして学ぶことを目的としています。

DDD は「ソフトウェアを現実の問題領域（ドメイン）に沿って設計する」ための考え方です。しかし、その抽象度の高さゆえに、初学者にとってはとっつきにくいことも多いのではないでしょうか。

そこで本書では、難しい業務システムの仕様ではなく、誰もが一度は耳にした「桃太郎」のストーリーを使って、ドメインモデリングの基本を体験できるようにしました。

本書で学べること

本書を通して、読者の皆さんは次のようなことを学ぶことができます。

• 文章から名詞を抽出し、モデルの素材を見つける方法
• エンティティと値オブジェクトの違いを見極める観点
• 動詞を手がかりに、名詞同士の「関係」を見つける方法
• 「時間」や「状態変化」をモデリングにどう取り込むか
• Factory・Repository・Service といった DDD を支える技術パターンの考え方
• そして、チームで言葉を揃え、共通理解を築くモデリングのプロセスそのもの

読み進め方

各章は「桃太郎の物語 → ドメインモデリングの解説 → 実際のシステム開発での示唆」という流れになっています。

最初に文章から名詞を拾い、それを仕分けし、動詞を手がかりにして関連をつける。 そこから時間の流れや状態遷移を加え、最終的に DDD の技術パターンに進む構成です。

桃太郎のストーリーを追いながら読み進めることで、自然にドメインモデリングの発想に触れることができます。

本書のゴール

DDD は決して「図を描くこと」や「パターンを当てはめること」が目的ではありません。 本当に大切なのは、「チーム全体で共通の言葉を育て、業務を理解し、システムに反映すること」です。

その第一歩として、「名詞を拾う」「分類してみる」「関係性を見つける」「変化を整理する」といった演習を一緒に体験しながら、DDD の考え方を実感していただければ幸いです。

第 1 章　桃太郎で学ぶドメインモデリング入門

1.1 文章から始めるモデリング

ドメインモデリングの最初の一歩は、とてもシンプルです。文章を読み、その中から「名詞」を拾い出すことから始まります。

なぜ名詞なのでしょうか。 それは名詞こそが、システムに登場する「モノ」や「人」、そして「出来事」を表す手がかりだからです。

たとえば、あなたが「旅行計画アプリ」を作るとします。会話の中で「宿泊先」「日程」「参加者」「予算」という言葉が出てきたとしましょう。これらはすべて名詞であり、そのままアプリに必要な要素（エンティティや値オブジェクト）へとつながります。

桃太郎の物語でも同じです。物語の文章を読んで名詞を拾うことで、その世界に「どんな登場人物がいるのか」「どんな物や場所が出てくるのか」が見えてきます。

現実の業務システムでも、最初に行う作業はこの「名詞拾い」です。仕様書やユーザーとの会話の中から用語を探すことで、モデリングの素材を手に入れることができます。これは、ちょうど料理の前に食材を集めるようなものです。どんなに立派な料理人でも、素材がなければ料理は作れませんよね。

コラム：もし桃太郎がシステム開発だったら？

桃太郎の物語を「システム開発プロジェクト」と見立てると面白い発見があります。

• 桃太郎＝「システムの主人公」
• 仲間（犬・猿・キジ）＝「関連エンティティ」
• 鬼退治＝「達成すべきビジネス課題」
• 宝物＝「得たい成果（利益や価値）」

つまり、物語を読むことは「業務のストーリー」をなぞることに近いのです。 プロジェクトにも主人公がいて、仲間がいて、倒すべき課題があり、最終的に得たい成果があります。

1.2 桃太郎の冒頭文を読む

では実際に、桃太郎の冒頭部分を読んでみましょう。

むかしむかし、あるところにおじいさんとおばあさんが住んでいました。 おじいさんは山へしばかりに、おばあさんは川へ洗濯に行きました。 おばあさんが川で洗濯をしていると、大きな桃がどんぶらこ、どんぶらこと流れてきました。 おばあさんは桃を家に持ち帰り、おじいさんと一緒に割ってみると、中から元気な男の子が出てきました。

この短い文章の中には、いくつもの名詞が隠れています。 おじいさん・おばあさんといった人物、川や山といった場所、桃や家といった物。さらには「洗濯」「しばかり」といった行動を示す名詞も含まれています。

たとえば業務システムで考えると、これは「販売管理システム」の仕様書に「顧客」「商品」「注文」といった名詞が並んでいるのと同じです。名詞に注目すると、ストーリーの登場人物や背景から、自然に「業務に関わる対象」が見えてくるのです。

たとえ話：会話の中の「宝探し」

名詞を拾い出す作業は、会話の中で宝探しをするようなものです。 「洗濯」「桃」「男の子」など、物語の文章の中に隠された宝石のような言葉を見つけていきます。

現場の会話でも同じです。ユーザーが「この帳票は毎月必要です」と言えば「帳票」が名詞になります。 エンジニアが「承認フローが複雑です」と言えば「承認フロー」が名詞です。

言葉の中から名詞を拾い出すことで、ドメインの“宝物”が少しずつ姿を現してくるのです。

1.3 名詞をハイライトする

では実際に、先ほどの文章から名詞を拾い出してみましょう。

むかしむかし、あるところにおじいさんとおばあさんが住んでいました。 おじいさんは山へしばかりに、おばあさんは川へ洗濯に行きました。 おばあさんが川で洗濯をしていると、大きな桃がどんぶらこ、どんぶらこと流れてきました。 桃を家に持ち帰り、おじいさんと一緒に割ってみると、中から元気な男の子が出てきました。

このように名詞をハイライトすると、「世界に何が存在しているか」が一目でわかります。

• 登場人物：おじいさん、おばあさん、男の子
• モノ：桃、家
• 場所：川、山、ところ
• 行動名詞：洗濯、しばかり

この段階では、「何が重要で、何が背景にすぎないか」をまだ決めなくて構いません。 目的はあくまで素材集めです。

現実のシステム開発でも、まずは用語カードを並べるように名詞を拾い出すことがよく行われます。例えばホワイトボードに付箋を貼って、「顧客」「商品」「注文」「請求書」などを出していくのです。こうして素材を揃えておくと、後で「どれを中心に据えるか」「どれは補助的な存在か」を考えるときに、とても役立ちます。

これはちょうど、RPG ゲームで最初に「どんなキャラクターやアイテムが登場するのか」を一覧にするのと同じです。ゲームの世界を理解するのに、登場キャラや道具のリストは欠かせませんよね。ドメインモデリングも同じで、「世界の登場要素をリスト化する」ことから始まります。

ミニワーク：あなたのプロジェクトで名詞を探そう

1. あなたが関わっているプロジェクトを思い浮かべてください。
2. 最近の会話やドキュメントを読み返し、出てきた名詞を付箋に書き出してみましょう。
3. その名詞を「人」「物」「場所」「出来事」にざっくり分けてみてください。

👉 たとえば営業支援システムなら、「営業担当」「顧客」「商談」「契約」「見積書」といった言葉が出てくるはずです。 こうした名詞が、モデリングの“最初の素材”になります。

まとめ

• モデリングの始まりは「名詞探し」である
• 名詞を拾い出すことで「世界に何が存在しているか」が見える
• すぐに分類せず、まずは素材を揃えることが大切
• 会話やドキュメントは“宝の山”。そこから名詞を掘り出す

1.5 名詞を一覧にまとめる

名詞を拾い出したら、次はそれを一覧表に整理してみましょう。

抽出された名詞一覧
おじいさん
おばあさん
川
山
洗濯
しばかり
桃
家
男の子
ところ

表にすると、一目で「どんな世界が広がっているのか」が見渡せます。 ここでは「これは重要そうだな」「これは背景にすぎないかもしれない」といった判断はまだ不要です。

現実の業務システムでも同じです。まずは顧客、商品、注文、請求書、配送、担当者……といった名詞をカードや付箋に書き出し、机やホワイトボードに並べます。この作業はまさにレゴブロックをテーブルいっぱいに広げるようなものです。まずは素材を出し切ってから、どう組み合わせるかを考えるのです。

コラム：名詞拾いの落とし穴

ただし、名詞を拾うときに注意が必要です。 文章に出てくる名詞がすべて「モデリング対象」になるわけではありません。

たとえば桃太郎の冒頭には「むかしむかし、あるところに……」という表現があります。ここでの「むかし」や「ところ」は、物語の雰囲気を伝えるだけで、システムのモデルに直接影響はありません。

業務でも同じで、「会議」「雑談」といった言葉が出てきても、それがシステム上で管理される必要がなければモデリング対象にはなりません。“名詞＝すべて重要”ではないということを頭に入れておきましょう。

第 2 章　エンティティと値オブジェクト、そして関連づけ

2.1 名詞を仕分けする

第 1 章で文章から名詞を拾い出しました。 次のステップは、それらを エンティティ（Entity） と 値オブジェクト（Value Object） に仕分けすることです。

• エンティティ：識別子（ID など）を持ち、時間とともに状態が変化するもの
• 値オブジェクト：識別子を持たず、意味が同じなら区別しないもの

2.2 エンティティと値オブジェクトの観点

名詞を並べ終えたら、次のステップは分類です。 DDD では大きく「エンティティ（Entity）」と「値オブジェクト（Value Object）」に分けて考えます。

エンティティの特徴

• 識別子（ID など）を持つ
• ライフサイクルがあり、時間とともに変化する
• 名前や状態が変わっても「同じ存在」として扱う

たとえば「社員」はエンティティです。異動や昇進があっても、社員 ID は同じで、同一人物として追跡されます。

値オブジェクトの特徴

• 識別子を持たない
• 意味や値が同じであれば区別せず、等価性で比較する
• 状態を変化させず、不変であることが望ましい

例としては「金額」や「住所」があります。1000 円札 A と 1000 円札 B を区別する必要はなく、両方とも「1000 円」として扱います。

2.3 桃太郎の名詞を分類してみる

それでは、先ほどの名詞を仮に分類してみましょう。

名詞	仮分類	理由（簡易）
おじいさん	エンティティ	個体識別が必要、状態変化がある
おばあさん	エンティティ	同上
川	値オブジェクト	特定性が薄く、背景説明にすぎない
山	値オブジェクト	同上
洗濯	値オブジェクト	動作名詞。状態を持たない
しばかり	値オブジェクト	同上
桃	値オブジェクト	消費されて終わり、識別不要
家	値オブジェクト	特定性が薄く、背景要素に近い
男の子	エンティティ	成長し、物語の中心となる
ところ	値オブジェクト	抽象的で識別が難しい

2.4 エンティティの具体例

「おじいさん」「おばあさん」「男の子（桃太郎）」はエンティティです。

たとえば業務システムに置き換えると、「おじいさん＝社員」「おばあさん＝顧客」「男の子＝新規ユーザー」といったイメージになります。 これらはすべて固有の存在で、識別子が必要です。

桃太郎は子どもから成長し、仲間を集め、鬼を倒します。これは「顧客」が契約を結び、商品を購入し、長期的に関係を築いていくのと同じです。時間とともに状態が変わっていくため、エンティティに分類されます。

2.5 値オブジェクトの具体例

一方で「桃」はどうでしょうか。 桃は物語の重要なきっかけですが、一度割られたら終わりです。桃 A と桃 B を区別する必要はありません。

これは「割引クーポン」に似ています。クーポンは使えばなくなるし、個体識別は不要です。重要なのは「10％引き」という意味だけです。

「川」「山」も同じです。背景を説明するために登場しますが、どの川かを識別する必要はありません。 これは「郵便番号」で示される住所の一部と同じで、意味が伝われば十分です。

ミニワーク：あなたの名詞を分類してみよう

1. 先ほど付箋に書いた名詞を思い出してください。
2. それぞれに「エンティティ」か「値オブジェクト」かを仮で分類してみましょう。
3. 判断に迷ったら「識別子が必要か？」「時間とともに変化するか？」を基準に考えてみてください。

👉 例えば「顧客」はエンティティですが、「住所」は値オブジェクト。 「注文」はエンティティですが、「金額」は値オブジェクトです。

2.6 動詞を手がかりに関連を見つける

名詞を分類したら、次にやるべきことは 関係をつけることです。 名詞だけでは世界は「バラバラな部品」で止まってしまいます。 そこで役立つのが 動詞です。

文章の中で「誰が」「何をする」「何に」という関係を探してみましょう。 英語文法でいう 第 3 文型（SVO） や 第 4 文型（SVOO） がそのヒントになります。

桃太郎の冒頭文から

• 「おじいさん は 山 へ しばかり に 行きました」 → おじいさん → 行く → 山
• 「おばあさん は 川 で 洗濯 を しました」 → おばあさん → 洗濯する → 川
• 「おばあさん は 桃 を 家 に 持ち帰りました」 → おばあさん → 持ち帰る → 桃／家
• 「おじいさん と おばあさん は 桃 を 割りました」 → おじいさん・おばあさん → 割る → 桃

こうして動詞を手がかりに関係を描くと、物語の構造が立体的に見えてきます。

2.7 関係を図にしてみる

動詞から導いた関係を整理すると次のようになります。

• おじいさん → 行く → 山
• おばあさん → 洗濯する → 川
• おばあさん → 持ち帰る → 桃 → 家
• おじいさん・おばあさん → 割る → 桃

これを線でつないで図にすると、名詞同士の「つながり」が浮かび上がり、ドメインモデルの基礎ができます。

コラム：レゴブロックを組み立てるように

名詞は「レゴの部品」。 動詞はそれを「つなげるポッチ」のようなものです。 部品を並べただけではただの山ですが、つなげると「船」や「家」になるように、 関係を加えることでモデルは初めて「動く世界」になります。

2.8 実務での応用例

桃太郎を業務に置き換えるとどうなるでしょうか？

• 「顧客 が 商品 を 注文する」
• 「社員 が 申請 を 提出する」
• 「ユーザー が ログインする」

これらはすべて、エンティティ同士や値オブジェクトをつなぐ関係です。 業務会話の中で「A が B する」「X が Y に影響する」という文章を拾うと、自然に関係が見えてきます。

2.9 ミニワーク：あなたのプロジェクトで関係を探そう

1. ドキュメントや会話から名詞を 10 個拾う
2. 動詞を探して「誰が → 何をする → 何に」の関係に整理する
3. それを線で結んで簡単なモデル図にする

👉 こうしてみると「顧客 → 注文 → 商品」「社員 → 申請 → 上司承認」といった業務の流れが浮かび上がります。

まとめ

• 名詞を拾ったら、まずは一覧にして整理する
• その中から「エンティティ」と「値オブジェクト」に分類する
• 分類の基準は「識別子が必要か」「時間とともに変化するか」
• 名詞は「エンティティ」と「値オブジェクト」に仕分けられる
• 動詞を手がかりにすると、名詞同士を関係づけられる
• 関係をつけることでモデルは「動き出す世界」となる
• 実務でも「A が B する」という文章を拾うだけで、自然にモデルが作れる

第 3 章　モデルと時間 ― 状態遷移とライフサイクル

3.1 モデルは動き続ける

第 2 章では、名詞を仕分けし、動詞を手がかりに名詞同士を関係づけることで、静的なモデルを組み立てました。 しかし、現実世界も物語も「静止画」ではありません。時間の流れとともに、エンティティは変化します。

桃太郎も同じです。

• 生まれたばかりの子ども
• 成長して仲間を集める青年
• 鬼と戦う戦士
• 村に帰って英雄となる存在

これらはすべて同じ「桃太郎」というエンティティですが、時間とともに状態が変わるのです。

3.2 状態遷移図で変化を表す

このような変化を整理するために役立つのが、**状態遷移図（ステートマシン）**です。

桃太郎の状態遷移

1. 準備中：村で生活している
2. 旅の途中：仲間を集めながら鬼ヶ島へ
3. 戦闘中：鬼と戦っている
4. 勝利：鬼を倒し宝を得た
5. 帰還済み：村に戻り英雄となる

図にするとこうなります。

3.3 実務システムでの例

状態遷移は業務システムでも頻繁に現れます。

• 注文システム
  • 作成中 → 承認済み → 発送済み → 完了
• 契約管理
  • 下書き → 承認待ち → 有効 → 解約
• ワークフロー
  • 起票 → 上司承認待ち → 承認済み → 完了

これらは「単なるフラグ管理」として済ませてしまうと分かりづらくなります。 状態遷移図として整理すれば「どの状態で何が可能か」「不正な操作は何か」が一目でわかります。

3.4 状態を意識するメリット

1. 不正操作を防ぐ
   • 準備中に鬼と戦えない
   • 下書き中の注文を発送できない
2. ビジネスルールが明確になる
   • 勝利したら必ず宝物を得る
   • 承認済み契約は必ず有効化される
3. テストがしやすい
   • 各状態に応じた処理をユニットテストできる
   • 状態の抜け漏れを防げる

コラム：すごろくで考える状態遷移

状態遷移は「すごろく」に例えるとわかりやすいです。 スタートからゴールまで順番にマスを進み、途中で仲間を得たり、鬼を倒したりします。

逆戻りしたり、順番を飛ばしたりできないようにするのが、状態遷移のルールです。 ゲームにルールがあるように、業務にもルールがあります。

3.5 注意点 ― 状態爆発に気をつける

状態を増やしすぎると、かえってモデルが複雑になってしまいます。

たとえば桃太郎を細かく表現しすぎると：

• 出発準備中（きびだんご未準備）
• 出発準備中（きびだんご準備済み）
• 仲間集め中（犬のみ）
• 仲間集め中（犬と猿）
• …

といった「状態爆発」が起こります。 これは設計を難しくし、開発・運用コストを上げてしまいます。

👉 必要十分な状態だけを定義することが大切です。

3.6 ミニワーク：状態遷移を書いてみよう

1. あなたの業務から「状態を持つもの」を 1 つ選びましょう。
   • 例：注文、申請、契約、ユーザーアカウント
2. そのライフサイクルを時系列で並べてみてください。
3. 「飛ばせない順序」「戻れない制約」がどこにあるか確認しましょう。

👉 実際に描いてみると「承認を飛ばしてリリースしていた」「本来戻せない処理を戻している」など、業務の“ひずみ”が見えてきます。

まとめ

• 名詞と動詞で作ったモデルに「時間の要素」を加えると、より実践的になる
• 状態遷移図を描くことで、変化とルールを明示できる
• 不正操作の防止、ビジネスルールの整理、テスト容易性などメリットが大きい
• ただし「状態爆発」には注意し、必要十分な粒度に留めることが重要

第 4 章　 DDD を支える 3 つの技術パターン

4.1 モデルだけでは足りない？

第 1〜3 章では、名詞を拾い、エンティティと値オブジェクトを仕分け、動詞を手がかりに関係をつけ、さらに時間の流れ（状態遷移）を意識するところまで進めました。 これで「ドメインの構造と変化」をモデル化できるようになりました。

しかし、実際のシステム開発ではそれだけでは不十分です。

• 複雑なオブジェクトをどうやって安全に生成するか？
• 永続化（DB 保存）の詳細をモデルに入れてしまうと複雑にならないか？
• 複数のモデルにまたがるビジネスルールは、どこに書けばいいのか？

こうした課題を整理するために登場するのが、DDD を支える「3 つの技術パターン」―― Factory（生成）／Repository（永続化）／Service（横断的なルール） です。

4.2 Factory：複雑な生成は外に出す

Factory とは？

Factory（ファクトリー）は「複雑な生成処理を隠蔽する」役割を持ちます。 単純に new で作れるものは不要ですが、生成にルールがある場合は Factory を使います。

• 生成に特別な条件がある
• 初期化に複雑な手順が必要
• 依存オブジェクトが多い

例え話：桃太郎のチーム結成

鬼退治チームを結成するには：

• 桃太郎本人
• 犬・猿・キジの仲間
• 交渉材料のきびだんご

これらを揃える必要があります。 単に new 桃太郎() では鬼退治チームはできません。 このように「正しい形で生成する窓口」こそが Factory の役割です。

コードイメージ

class TeamFactory {
  Team createTeam() {
    桃太郎 leader = new 桃太郎();
    List<仲間> friends = 仲間交渉ルール.apply(きびだんご);
    return new Team(leader, friends);
  }
}

4.3 Repository：永続化を隠す倉庫

Repository とは？

Repository（リポジトリ）は「エンティティを保存・取得するための抽象的な窓口」です。 モデルからは「保存」「検索」という意図だけを見せ、DB やファイルの実装は隠します。

例え話：村の台帳は Repository

• 村の台帳に「桃太郎」という住人が登録されている
• 鬼退治の成果を「討伐記録」として残す
• 宝物の一覧を管理する

これらはすべて「永続化」の仕組みであり、Repository の役割にあたります。

コードイメージ

interface 桃太郎Repository {
  桃太郎 findByName(String name);
  void save(桃太郎 hero);
}

コラム：Repository がないとどうなる？

もしエンティティの中に直接 SQL を書いたらどうでしょう？ 「桃太郎クラス」に SELECT * FROM villagers... のようなコードが入り込み、 ビジネスロジックとデータアクセスが混ざってしまいます。

Repository を設けることで、モデルとインフラの責任を分離でき、保守もテストも容易になります。

4.4 Service：横断的なビジネスルールの器

Service とは？

Service（サービス）は、エンティティや値オブジェクト単体では表現しにくい「横断的なビジネスルール」をまとめる場所です。 「誰がやるか」よりも「何をするか」が大切な処理は、Service に置きます。

例え話：鬼退治はサービスの仕事

鬼退治の流れを考えてみましょう。

• 桃太郎（リーダー）
• 仲間（犬・猿・キジ）
• 鬼（敵）
• 宝物（報酬）

これらをまたいで「仲間と協力して鬼を倒し、宝を得る」という処理をまとめるのが Service です。

コードイメージ

class 鬼退治サービス {
  void execute(桃太郎 hero, List<仲間> friends, 鬼 enemy) {
    if (friends.isEmpty()) throw new RuntimeException("仲間が必要です");
    enemy.defeat();
    宝物 loot = enemy.getTreasure();
    hero.obtainTreasure(loot);
  }
}

4.5 3 つのパターンの整理

パターン	役割	桃太郎のたとえ
Factory	正しい生成を担う	チーム結成
Repository	永続化を隠して扱う	村の台帳、討伐記録
Service	横断的なビジネスルールをまとめる	鬼退治のプロセス

4.6 ミニワーク：あなたのプロジェクトで探してみよう

1. Factory：新規作成にルールがあるものは？
   • 例：社員登録時に社員番号を採番する
2. Repository：保存・検索の頻度が高いものは？
   • 例：顧客情報、商品カタログ
3. Service：複数のモデルをまたいで成り立つ処理は？
   • 例：顧客が商品を購入し、請求が発行される流れ

まとめ

• モデルを現実的に支えるのは Factory／Repository／Service
• Factory は「正しい生成」を保証し、Repository は「永続化」を隠し、Service は「横断的なルール」を整理する
• 桃太郎の物語に置き換えると、自然に理解できる
• 実務のシステムでも、3 つのパターンを意識するだけで責任分担が明確になる

第 5 章　まとめと実践へのステップ

5.1 桃太郎から学んだこと

ここまで、桃太郎の物語を題材にしてドメインモデリングを学んできました。

• 名詞拾い：登場する要素を言葉から抽出する
• エンティティと値オブジェクト：変化する存在と意味だけの存在を区別する
• 関係づけ：動詞を手がかりに名詞同士を結ぶ
• 時間と状態遷移：変化をモデルに組み込む
• 技術パターン：Factory／Repository／Service で裏方を整理する

桃太郎の物語を通じて、「世界の言葉をモデルに置き換える」プロセスを体験できました。

5.2 実務にどう活かすか？

業務システムは桃太郎の物語より複雑ですが、進め方は同じです。

1. 会話や仕様書から名詞を拾う
2. エンティティと値オブジェクトに仕分ける
3. 動詞を手がかりに関係を見つける
4. 時間の流れや状態遷移を整理する
5. Factory／Repository／Service でモデルを支える

このサイクルを繰り返すことで、複雑な業務も整理できるようになります。

5.3 読者への問いかけ

• あなたのプロジェクトの「桃太郎（主人公）」は誰ですか？
• どんな「仲間（関連エンティティ）」が存在しますか？
• どんな「鬼（課題や制約）」を倒す必要がありますか？
• それによって得られる「宝物（価値や成果）」は何でしょうか？

自分のプロジェクトを物語に重ねることで、モデリングがぐっと身近になります。

5.4 次のステップ

1. 小さな題材で練習する
   • 飲み会管理や旅行計画など身近なテーマで名詞拾いを試してみる
2. 付箋やカードを使う
   • 名詞をカードにして並べると、関係が直感的に見える
3. チームで言葉を揃える
   • 「その言葉はどういう意味？」を確認し合うことがモデルの強さにつながる
4. 技術パターンを意識する
   • コードに「これは Factory か？」「Repository に分けるべきか？」という視点を持つ

5.5 本書のゴール

ドメイン駆動設計は「難しい設計手法」ではなく、 「言葉を揃えて、物語をシステムに写し取る方法論」です。

桃太郎という昔話を題材にすることで、少しでも「モデリングは面白い」「実務に応用できそう」と感じていただけたなら、本書の目的は達成されたと言えるでしょう。

まとめ

• モデリングは「名詞拾い」から始まる
• エンティティ／値オブジェクトの分類と動詞による関係づけで世界を形づくる
• 状態遷移を加えると、時間を通した変化が表現できる
• Factory／Repository／Service の技術パターンがモデルを支える
• 物語をシステムに写すことこそが DDD の本質である

付録

付録 A：名詞拾いチェックリスト

文章や会話から名詞を拾うときの観点をまとめました。

• 人：登場人物、担当者、ユーザー、顧客など
• 物：商品、資産、ツール、資料など
• 場所：拠点、支店、サービスエリアなど
• 出来事：注文、契約、申請、会議など
• 抽象的なもの：目的、役割、ルール、制約など

👉 これらを付箋に書き出し、机やホワイトボードに並べると、モデリングの材料が一気に見えてきます。

付録 B：関係づけのための文型ヒント

動詞を手がかりに関係を探す際、英語の文型が役立ちます。

• 第 3 文型（SVO）
  • 「A が B をする」
  • 例：顧客が注文をする、社員が申請を出す
• 第 4 文型（SVOO）
  • 「A が B に C を与える」
  • 例：上司が部下に仕事を割り当てる、システムがユーザーに通知を送る

付録 C：演習課題

本書で学んだ内容を、自分の業務に当てはめて練習してみましょう。

1. 最近の会話や仕様書から名詞を 10 個拾う
2. それをエンティティと値オブジェクトに分類する
3. 動詞を手がかりに関係を見つける
4. 状態遷移図を 1 つ描いてみる
5. Factory／Repository／Service の候補を考える

参考文献

• エリック・エヴァンス『ドメイン駆動設計』翔泳社, 2011
• ヴォーン・ヴァーノン『実践ドメイン駆動設計』翔泳社, 2014
• James Coplien, Gertrud Bjørnvig, Lean Architecture for Agile Software Development, Wiley, 2010
• Greg Young, CQRS Documents, InfoQ, 2010
• Evans, Eric. Domain-Driven Design Reference, 2014 (オンライン公開資料)

---

桃太郎（全文）

むかしむかし、あるところに、おじいさんとおばあさんが住んでいました。

おじいさんは山へしばかりに、おばあさんは川へ洗濯に行きました。

おばあさんが川で洗濯をしていると、川上からどんぶらこ、どんぶらこと、大きな桃が流れてきました。
おばあさんは「これはいいおみやげになる」と思い、その桃を家に持ち帰りました。

家に戻り、おじいさんと一緒に桃を割ってみると、中から元気な男の子が飛び出してきました。
子どもがいなかったおじいさんとおばあさんは大喜びで、その子を「桃から生まれた桃太郎」と名づけて、大切に育てました。

桃太郎はすくすくと育ち、強い若者になりました。
やがて「鬼ヶ島に悪い鬼たちがいて、人々の宝物を奪って困らせている」と聞きました。
桃太郎は「鬼を退治して人々を助けよう」と決意し、旅に出ることにしました。

おばあさんが作ってくれたきびだんごを腰に下げて出発すると、道中で犬、猿、キジが現れました。
それぞれ「きびだんごをひとつください。その代わりに鬼退治のお供をします」と言い、桃太郎は仲間として連れて行きました。

やがて一行は鬼ヶ島にたどり着きました。
桃太郎と犬、猿、キジは力を合わせて鬼たちと戦い、ついに鬼の頭領を打ち負かしました。
鬼たちは降参し、奪った宝物や財宝をすべて差し出しました。

桃太郎たちは宝物を持ち帰り、村の人々に分け与えました。
おじいさんとおばあさんも大喜びし、村は平和になりました。

めでたし、めでたし。

---

あとがき

「ドメイン駆動設計（DDD）」と聞くと、多くの人は「難しそう」「エリートエンジニア向け」という印象を持つかもしれません。 私自身も最初に DDD を学んだときは、専門用語や抽象的な概念に圧倒されました。

しかし、あるとき「桃太郎」という物語を題材にして説明してみると、驚くほど多くの人が理解してくれました。 それは、DDD が本質的に「物語を言葉にしてシステムに写す作業」だからです。

本書では、名詞を拾い、分類し、関係をつけ、時間の流れを表現するという一連の流れを桃太郎で体験しました。 もちろん、現実の業務はもっと複雑で、葛藤や例外もたくさんあります。 それでも「世界を言葉で切り取り、チームで共有する」という姿勢は変わりません。

読者の皆さんが、この本をきっかけに「自分たちの業務の桃太郎物語」を語り、モデルにし、よりよいシステムを育てていけることを願っています。

最後まで読んでいただき、本当にありがとうございました。