AI時代におけるドメイン駆動設計 入門 / Introduction to Domain-Driven Design in the AI ​​Era

PHPカンファレンス福岡2025で発表した内容になります!
「AI時代におけるドメイン駆動設計 入門」
https://fortee.jp/phpcon-fukuoka-2025/proposal/5fcfed30-405f-4cbd-a18a-7d087d5c7fc8

Transcript

1. AI時代における ドメイン駆動設計 入門 2025/11/08 PHPカンファレンス福岡2025
2. 自己紹介 氏名: 遠藤太徳 (Endo Futoshi) 所属: NewRelic株式会社(New Relic, K.K.) 業務: TAM(Technical Account Manager) 経歴: 2017/04 GMOペパボ株式会社 Software Engineer 2023/01 BASE株式会社 Software Engineer 2025/10 NewRelic株式会社 TAM PHP歴は9年程🐘 趣味: 音楽、料理、散歩、ゲーム、個人開発、どんちゃん
3. https://speakerdeck.com/fendo181/behind-the-scenes-resolvin g-email-delays-for-an-e-commerce-service-using-new-relic-ap m https://speakerdeck.com/fendo181/introduction-to-design-pa tterns-with-php8
4. https://speakerdeck.com/fendo181/irt-study-session-improved- through-laravel-shibuya https://gihyo.jp/book/2019/978-4-297-11055-0
5. https://devblog.thebase.in/entry/backend-developers-perspec tive-learning-frontend-with-ai https://zenn.dev/fendo181/articles/6ed5dfc71898da
6. 免責事項
7. 01 スライドの内容は主に自分の業務経験で得た知見を元にスライドを 作成していますが、具体的な業務内容は言及せずに、抽象化した内 容になっています。 02 ドメイン駆動設計が少し難しい概念のため、スライドでは説明がしき れてない箇所が出てきます。その場合はぜひ「ドメイン駆動設計をは じめよう」 をよんでください! 3回!
8. https://x.com/masuda220/status/1980883239679238485 https://www.oreilly.co.jp/books/9784814400737/
9. アジェンダ
10. (1) ドメイン駆動設計が生まれた背景 (2) 複雑な業務ドメインを特定する (3) 生成AIを活用して作業を効率化する (4) まとめ
11. ドメイン駆動設計が 生まれた背景
12. • 2003年：エリック・エヴァンス（ Eric Evans）が著書の 「Domain-Driven Design: Tackling Complexity in the Heart of Software」が出版。 これがDDDの出発点
13. • 2003年：エリック・エヴァンス（ Eric Evans）が著書の 「Domain-Driven Design: Tackling Complexity in the Heart of Software」が出版。 これがDDDの出発点 • 本が出版された当時 (2003年)、 エンタープライズ向 けのソフトウェア開発が大規模・複雑化しており、 「技 術中心」ではなく「ビジネス中心」 での設計の重要性 が高まっていた。
14. • 2003年：エリック・エヴァンス（ Eric Evans）が著書の 「Domain-Driven Design: Tackling Complexity in the Heart of Software」が出版。 これがDDDの出発点 • 本が出版された当時 (2003年)、 エンタープライズ向 けのソフトウェア開発が大規模・複雑化しており、 「技 術中心」ではなく「ビジネス中心」 での設計の重要性 が高まっていた。 • DDDは、オブジェクト指向設計、アジャイル開発の流 れの中から登場したアプローチで特に複雑な業務ドメ イン扱うシステムで効果を発揮
15. • 2003年：エリック・エヴァンス（ Eric Evans）が著書の 「Domain-Driven Design: Tackling Complexity in the Heart of Software」が出版。 これがDDDの出発点 • 本が出版された当時 (2003年)、 エンタープライズ向 けのソフトウェア開発が大規模・複雑化しており、 「技 術中心」ではなく「ビジネス中心」 での設計の重要性 が高まっていた。 • DDDは、オブジェクト指向設計、アジャイル開発の流 れの中から登場したアプローチで特に複雑な業務ドメ イン扱うシステムで効果を発揮 • ドメインモデリングを行い、「エンティティ」、「値オブ ジェクト」、「集約」といった概念を使って、現実世界の 構造をそのままコードに落とし込んでいく
16. • 2003年：エリック・エヴァンス（ Eric Evans）が著書の 「Domain-Driven Design: Tackling Complexity in the Heart of Software」が出版。 これがDDDの出発点 • 本が出版された当時 (2003年)、 エンタープライズ向 けのソフトウェア開発が大規模・複雑化しており、 「技 術中心」ではなく「ビジネス中心」 での設計の重要性 が高まっていた。 • DDDは、オブジェクト指向設計、アジャイル開発の流 れの中から登場したアプローチで 特に複雑な業務ド メイン扱うシステムで効果を発揮 • ドメインモデリングを行い、「エンティティ」、「値オブ ジェクト」、「集約」といった概念を使って、現実世界の 構造をそのままコードに落とし込んでいく
17. Q. なぜ、DDD(ドメイン駆動設計)は複雑な業務ドメイン扱うシステム で効果を発揮するのか? MVCなどの他の設計でも同様の効果が 発揮するのではないか?
18. A. DDDの本質はデータの入出力を制御する設計がゴールではく、あくま でも、ビジネスの複雑さをソフトウェアに正しく「マッピングする」ことを 主眼に置いている。 (ドメインモデリング ) 業務ロジックが複雑化し、変更頻度が高いケースに特に有効 (例: ECにおける決済、在庫管理など) Q. なぜ、DDD(ドメイン駆動設計)は複雑な業務ドメイン扱うシステム で効果を発揮するのか? MVCなどの他の設計でも同様の効果が 発揮するのではないか?
19. • 2003年：エリック・エヴァンス（ Eric Evans）が著書の 「Domain-Driven Design: Tackling Complexity in the Heart of Software」が出版。 これがDDDの出発点 • 本が出版された当時(2003年)、 エンタープライズ向 けのソフトウェア開発が大規模・複雑化 しており、 「技術中心」ではなく「ビジネス中心」での設計の重要 性が高まっていた。 • DDDは、オブジェクト指向設計、アジャイル開発の流 れの中から登場したアプローチで 特に複雑な業務ド メイン扱うシステムで効果を発揮 • ドメインモデリングを行い、「エンティティ」、「値オブ ジェクト」、「集約」といった概念を使って、現実世界の 構造をそのままコードに落とし込んでいく
20. • 2003年：エリック・エヴァンス（ Eric Evans）が著書の 「Domain-Driven Design: Tackling Complexity in the Heart of Software」が出版。 これがDDDの出発点 • 本が出版された当時(2003年)、 エンタープライズ向 けのソフトウェア開発が大規模・複雑化 しており、 「技術中心」ではなく「ビジネス中心」での設計の重要 性が高まっていた。 • DDDは、オブジェクト指向設計、アジャイル開発の流 れの中から登場したアプローチで 特に複雑な業務ド メイン扱うシステムで効果を発揮 • ドメインモデリングを行い、「エンティティ」、「値オブ ジェクト」、「集約」といった概念を使って、現実世界の 構造をそのままコードに落とし込んでいく • 日本語翻訳は2011年に出版されました。
21. Q. 「複雑な業務ドメイン」とはなんですか? なにをもって複雑と 定義するのですか?
22. 複雑な業務ドメインを整 理する
23. • 2021年11月に発売。著者はヴラド ホノノフ氏(Vlad Khononov)。 • 日本語訳は2024年07月に発売。
24. • 2021年11月に発売。著者はヴラド ホノノフ氏(Vlad Khononov)。 • 日本語訳は2024年07月に発売。 • 事業活動とソフトウェアを一緒に発展させていく こと について一貫して書かれている
25. “中核の業務領域だけが競争優位を生 み出します。中核の業務領域は競合他 社との差別化を図る事業戦略の核心で す。”
27. 小 一般 中核の 業務領域 一般または補完 補完 大 大 競走他社との差別化 業務ロジック の複雑さ
28. 小 競走他社との差別化 業務ロジック の複雑さ 一般的な業務領域(Generic Subdomain）: 他の多くのシステムでも共通して存在する、汎用的な機能領域。 特定のビジネス価値を生まないが、アプリケーションを支える土台となる。 (例: 認証・認可（Auth, JWT, OAuth）、ログ収集・監視、メール基盤など )
29. 小 競走他社との差別化 業務ロジック の複雑さ 一般的な業務領域(Generic Subdomain）: 他の多くのシステムでも共通して存在する、汎用的な機能領域。 特定のビジネス価値を生まないが、アプリケーションを支える土台となる。 (例: 認証・認可（Auth, JWT, OAuth）、ログ収集・監視、メール基盤など ) 補完的な業務領域（Supporting Subdomain）: 中核の業務領域を支える、業務ロジックを持つが差別化にはならない領域。 この部分がないとサービスは動かないが、競争優位はない。 (例: サインアップ・ログイン画面、在庫・メニュー管理画面など )
30. 小 競走他社との差別化 業務ロジック の複雑さ 一般的な業務領域(Generic Subdomain）: 他の多くのシステムでも共通して存在する、汎用的な機能領域。 特定のビジネス価値を生まないが、アプリケーションを支える土台となる。 (例: 認証・認可（Auth, JWT, OAuth）、ログ収集・監視、メール基盤など ) 補完的な業務領域（Supporting Subdomain）: 中核の業務領域を支える、業務ロジックを持つが差別化にはならない領域。 この部分がないとサービスは動かないが、競争優位はない。 (例: サインアップ・ログイン画面、在庫・メニュー管理画面など ) 中核の業務領域（Core Domain） 事業の競争優位を生む業務領域。ビジネス上の差別化ポイントで、複雑で、人の判断・経 験が必要。頻繁に変わり・成長する。 (例: 配達マッチング、動的価格設定、遅延時の自動補償判断、クーポンなど )
31. 小 一般 中核の 業務領域 一般または補完 補完 大 大 ログ収集・監視、メー ル基盤 認証・認可 小 競走他社との差別化 業務 ロジック の複雑さ
32. 小 一般 中核の 業務領域 一般または補完 補完 大 大 ログ収集・監視、メー ル基盤 認証・認可 ログイン画面 在庫・メニュー管理 レポート生成 小 競走他社との差別化 業務 ロジック の複雑さ
33. 小 一般 中核の 業務領域 一般または補完 補完 大 大 ログ収集・監視、メー ル基盤 認証・認可 ログイン画面 在庫・メニュー管理 レポート生成 配達マッチング 動的価格設定 クーポン 決済手段 小 競走他社との差別化 業務 ロジック の複雑さ
34. 小 一般 中核の 業務領域 一般または補完 補完 大 大 ログ収集・監視、メー ル基盤 認証・認可 ログイン画面 在庫・メニュー管理 レポート生成 配達マッチング 動的価格設定 クーポン 決済手段 小 競走他社との差別化 業務 ロジック の複雑さ
35. Q. 「複雑な業務ドメイン」とはなんですか? なにをもって複雑と 定義するのですか?
36. A. その業務において競争優位がある業務領域 。 競合相手に真似できないようにする為、ここが自社の業績を生 み出す領域になっており、それゆえ業務が複雑になるため戦 略的に取り組む必要がある 。設計の優先順位の判断では「中 核の業務領域」を優先して対応を行う。 Q. 「複雑な業務ドメイン」とはなんですか? なにをもって複雑と 定義するのですか?
37. 生成AIを活用して 作業を効率化する
38. 競走他社との差別化 • 各領域（中核／補完・一般）で、生成AIの使用方法が変わる • 領域においてはコード生成を積極的に使う場面もあれば、情報を 整理する為に使う場面もある • 特にDDDでは、ドメインの理解 と「同じ言葉(ユビキタス言語 )」を 整理するのが重要
39. 競走他社との差別化 ①イベントストーミング を通じて、業務イベントを整理する 。 (ドメインエキスパートがいない場合は、コードリーディングやドキュメントを 漁って業務イベントを整理)
40. 競走他社との差別化 ②業務イベント、コマンドを洗い出す中で共通な機能や、概念を まとめる(集約をふわっと作成し、区切られた文脈 を整理する)
41. 競走他社との差別化 ③業務が整理していく中でエンジニアサイド、ビジネスサイドが使う「同じ言葉 (ユビキタス言語 )」を統一させる
42. 競走他社との差別化 ④議論を通じて出てきた言葉や、議事録の内容を生成AIで管理し、常に整 理された、最新の情報 が取れる状態にする
43. ドメイン駆動設計における生成 AIの活用例① • 業務会話ログ・仕様書・議事録をAIに読み込ませ、ドメイン用語・ 関係性を抽出。エンジニアがコードで使う用語とビジネスサイドが 会話で使う言葉を一致させる ◦ モデリングの出発点を整理できる • モデルレビュー・設計議論の壁打ち相手
44. 小 一般 中核の 業務領域 一般または補完 補完 大 大 小 競走他社との差別化 業務 ロジック の複雑さ ログイン画面 在庫・メニュー管理 レポート生成 配達マッチング 動的価格設定 クーポン 決済手段 ログ収集・監視、メール 基盤 認証・認可
45. 小 一般 中核の 業務領域 一般または補完 補完 大 大 小 競走他社との差別化 業務 ロジック の複雑さ AI Agentで生成 (他サービスで置き換えが可能 ) 生成AIを活用してドメインを 整理して、区切られた文脈 や、ドメインモデリングを用 意、実装を行う AI Agentで積極的に コードを生成する
46. • 中核の業務領域 では抽出した用語をもとに Entity、Value Object、Aggregate Root、UseCaseを整理、実装する • 一般・補完の業務領域 ではAI Agent(Claude Code、Codex、 Gemini CLI)活用する。またアーキテクトに関わるドキュメントを用意 して、生成するファイルの統一性をもたせる ドメイン駆動設計における生成 AIの活用例②
47. まとめ
48. • AI時代におけるドメイン駆動設計（DDD）は、生成AIの活用に よって、仕様書・会話ログ・議事録などからドメイン知識を抽出し、 ドメインモデリングの土台が整いやすくなった。 • 一方でまだまだ「中核の業務領域」においては人の判断は必要な ので、それぞれの業務領域で生成AIうまく活用するのが大事だと 感じています!
49. “ビジネス要求は変わり続け 、優先度の変更 もしょっちゅうです 。 しかもすべては「できるだけ速く 」です。そして、 研究開発をする余裕はほとんどありません。こ のような状況でドメイン駆動設計を受け入れ る事で、私たちはさまざまな複雑さに立ち向 かい、事業に貢献するソフトウェアを生み出し 続ける事ができました。つまり、振り返ってみ れば、ドメイン駆動設計に賭けた私たちは十 分な見返りを手に入れたのです。 ”
50. ご清聴ありがとうございました ! 🍜
51. • 「ドメイン駆動設計をはじめよう」を3回読んで学んだ事をまとめる • AI時代のソフトウェア開発を考える（2025/07版） / Agentic Software Engineering Findy 2025-07 Edition - Speaker Deck • ソフトウェア設計とAI技術の活用 - Speaker Deck • AI時代の『ドメイン駆動設計をはじめよう』 - Speaker Deck • ドメイン駆動設計のエッセンス - Speaker Deck • https://medium.com/nick-tune-tech-strategy-blog/core-domain-patterns- 941f89446af5 • Domain-Driven Design (DDD) / ドメイン駆動設計（DDD） • ドメイン駆動設計の正体 • ドメイン駆動設計の巨匠：ソフトウェア設計に革命をもたらした思想家/エリック ・エヴァンス｜hibara42 参考文献