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

by Futoshi Endo

Slide 1

Slide 1 text

AI時代におけるドメイン駆動設計入門 2025/11/08 PHPカンファレンス福岡2025

Slide 2

Slide 2 text

自己紹介氏名: 遠藤太徳 (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年程🐘 趣味: 音楽、料理、散歩、ゲーム、個人開発、どんちゃん

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

https://speakerdeck.com/fendo181/irt-study-session-improved- through-laravel-shibuya https://gihyo.jp/book/2019/978-4-297-11055-0

Slide 5

Slide 5 text

https://devblog.thebase.in/entry/backend-developers-perspec tive-learning-frontend-with-ai https://zenn.dev/fendo181/articles/6ed5dfc71898da

Slide 6

Slide 6 text

免責事項

Slide 7

Slide 7 text

01 スライドの内容は主に自分の業務経験で得た知見を元にスライドを作成していますが、具体的な業務内容は言及せずに、抽象化した内容になっています。 02 ドメイン駆動設計が少し難しい概念のため、スライドでは説明がしきれてない箇所が出てきます。その場合はぜひ「ドメイン駆動設計をはじめよう」をよんでください! 3回!

Slide 8

Slide 8 text

https://x.com/masuda220/status/1980883239679238485 https://www.oreilly.co.jp/books/9784814400737/

Slide 9

Slide 9 text

アジェンダ

Slide 10

Slide 10 text

(1) ドメイン駆動設計が生まれた背景 (2) 複雑な業務ドメインを特定する (3) 生成AIを活用して作業を効率化する (4) まとめ

Slide 11

Slide 11 text

ドメイン駆動設計が生まれた背景

Slide 12

Slide 12 text

● 2003年：エリック・エヴァンス（ Eric Evans）が著書の「Domain-Driven Design: Tackling Complexity in the Heart of Software」が出版。これがDDDの出発点

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

● 2003年：エリック・エヴァンス（ Eric Evans）が著書の「Domain-Driven Design: Tackling Complexity in the Heart of Software」が出版。これがDDDの出発点 ● 本が出版された当時 (2003年)、エンタープライズ向けのソフトウェア開発が大規模・複雑化しており、「技術中心」ではなく「ビジネス中心」での設計の重要性が高まっていた。 ● DDDは、オブジェクト指向設計、アジャイル開発の流れの中から登場したアプローチで特に複雑な業務ドメイン扱うシステムで効果を発揮 ● ドメインモデリングを行い、「エンティティ」、「値オブジェクト」、「集約」といった概念を使って、現実世界の構造をそのままコードに落とし込んでいく

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Q. なぜ、DDD(ドメイン駆動設計)は複雑な業務ドメイン扱うシステムで効果を発揮するのか? MVCなどの他の設計でも同様の効果が発揮するのではないか?

Slide 18

Slide 18 text

A. DDDの本質はデータの入出力を制御する設計がゴールではく、あくまでも、ビジネスの複雑さをソフトウェアに正しく「マッピングする」ことを主眼に置いている。 (ドメインモデリング ) 業務ロジックが複雑化し、変更頻度が高いケースに特に有効 (例: ECにおける決済、在庫管理など) Q. なぜ、DDD(ドメイン駆動設計)は複雑な業務ドメイン扱うシステムで効果を発揮するのか? MVCなどの他の設計でも同様の効果が発揮するのではないか?

Slide 19

Slide 19 text

● 2003年：エリック・エヴァンス（ Eric Evans）が著書の「Domain-Driven Design: Tackling Complexity in the Heart of Software」が出版。これがDDDの出発点 ● 本が出版された当時(2003年)、エンタープライズ向けのソフトウェア開発が大規模・複雑化しており、「技術中心」ではなく「ビジネス中心」での設計の重要性が高まっていた。 ● DDDは、オブジェクト指向設計、アジャイル開発の流れの中から登場したアプローチで特に複雑な業務ドメイン扱うシステムで効果を発揮 ● ドメインモデリングを行い、「エンティティ」、「値オブジェクト」、「集約」といった概念を使って、現実世界の構造をそのままコードに落とし込んでいく

Slide 20

Slide 20 text

● 2003年：エリック・エヴァンス（ Eric Evans）が著書の「Domain-Driven Design: Tackling Complexity in the Heart of Software」が出版。これがDDDの出発点 ● 本が出版された当時(2003年)、エンタープライズ向けのソフトウェア開発が大規模・複雑化しており、「技術中心」ではなく「ビジネス中心」での設計の重要性が高まっていた。 ● DDDは、オブジェクト指向設計、アジャイル開発の流れの中から登場したアプローチで特に複雑な業務ドメイン扱うシステムで効果を発揮 ● ドメインモデリングを行い、「エンティティ」、「値オブジェクト」、「集約」といった概念を使って、現実世界の構造をそのままコードに落とし込んでいく ● 日本語翻訳は2011年に出版されました。

Slide 21

Slide 21 text

Q. 「複雑な業務ドメイン」とはなんですか? なにをもって複雑と定義するのですか?

Slide 22

Slide 22 text

複雑な業務ドメインを整理する

Slide 23

Slide 23 text

● 2021年11月に発売。著者はヴラドホノノフ氏(Vlad Khononov)。 ● 日本語訳は2024年07月に発売。

Slide 24

Slide 24 text

● 2021年11月に発売。著者はヴラドホノノフ氏(Vlad Khononov)。 ● 日本語訳は2024年07月に発売。 ● 事業活動とソフトウェアを一緒に発展させていくことについて一貫して書かれている

Slide 25

Slide 25 text

“中核の業務領域だけが競争優位を生み出します。中核の業務領域は競合他社との差別化を図る事業戦略の核心です。”

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

小一般中核の業務領域一般または補完補完大大競走他社との差別化業務ロジックの複雑さ

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

小競走他社との差別化業務ロジックの複雑さ一般的な業務領域(Generic Subdomain）: 他の多くのシステムでも共通して存在する、汎用的な機能領域。特定のビジネス価値を生まないが、アプリケーションを支える土台となる。 (例: 認証・認可（Auth, JWT, OAuth）、ログ収集・監視、メール基盤など ) 補完的な業務領域（Supporting Subdomain）: 中核の業務領域を支える、業務ロジックを持つが差別化にはならない領域。この部分がないとサービスは動かないが、競争優位はない。 (例: サインアップ・ログイン画面、在庫・メニュー管理画面など ) 中核の業務領域（Core Domain）事業の競争優位を生む業務領域。ビジネス上の差別化ポイントで、複雑で、人の判断・経験が必要。頻繁に変わり・成長する。 (例: 配達マッチング、動的価格設定、遅延時の自動補償判断、クーポンなど )

Slide 31

Slide 31 text

小一般中核の業務領域一般または補完補完大大ログ収集・監視、メール基盤認証・認可小競走他社との差別化業務ロジックの複雑さ

Slide 32

Slide 32 text

小一般中核の業務領域一般または補完補完大大ログ収集・監視、メール基盤認証・認可ログイン画面在庫・メニュー管理レポート生成小競走他社との差別化業務ロジックの複雑さ

Slide 33

Slide 33 text

小一般中核の業務領域一般または補完補完大大ログ収集・監視、メール基盤認証・認可ログイン画面在庫・メニュー管理レポート生成配達マッチング動的価格設定クーポン決済手段小競走他社との差別化業務ロジックの複雑さ

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Q. 「複雑な業務ドメイン」とはなんですか? なにをもって複雑と定義するのですか?

Slide 36

Slide 36 text

A. その業務において競争優位がある業務領域。競合相手に真似できないようにする為、ここが自社の業績を生み出す領域になっており、それゆえ業務が複雑になるため戦略的に取り組む必要がある。設計の優先順位の判断では「中核の業務領域」を優先して対応を行う。 Q. 「複雑な業務ドメイン」とはなんですか? なにをもって複雑と定義するのですか?

Slide 37

Slide 37 text

生成AIを活用して作業を効率化する

Slide 38

Slide 38 text

競走他社との差別化 ● 各領域（中核／補完・一般）で、生成AIの使用方法が変わる ● 領域においてはコード生成を積極的に使う場面もあれば、情報を整理する為に使う場面もある ● 特にDDDでは、ドメインの理解と「同じ言葉(ユビキタス言語 )」を整理するのが重要

Slide 39

Slide 39 text

競走他社との差別化 ①イベントストーミングを通じて、業務イベントを整理する。 (ドメインエキスパートがいない場合は、コードリーディングやドキュメントを漁って業務イベントを整理)

Slide 40

Slide 40 text

競走他社との差別化 ②業務イベント、コマンドを洗い出す中で共通な機能や、概念をまとめる(集約をふわっと作成し、区切られた文脈を整理する)

Slide 41

Slide 41 text

競走他社との差別化 ③業務が整理していく中でエンジニアサイド、ビジネスサイドが使う「同じ言葉 (ユビキタス言語 )」を統一させる

Slide 42

Slide 42 text

競走他社との差別化 ④議論を通じて出てきた言葉や、議事録の内容を生成AIで管理し、常に整理された、最新の情報が取れる状態にする

Slide 43

Slide 43 text

ドメイン駆動設計における生成 AIの活用例① ● 業務会話ログ・仕様書・議事録をAIに読み込ませ、ドメイン用語・関係性を抽出。エンジニアがコードで使う用語とビジネスサイドが会話で使う言葉を一致させる ○ モデリングの出発点を整理できる ● モデルレビュー・設計議論の壁打ち相手

Slide 44

Slide 44 text

小一般中核の業務領域一般または補完補完大大小競走他社との差別化業務ロジックの複雑さログイン画面在庫・メニュー管理レポート生成配達マッチング動的価格設定クーポン決済手段ログ収集・監視、メール基盤認証・認可

Slide 45

Slide 45 text

小一般中核の業務領域一般または補完補完大大小競走他社との差別化業務ロジックの複雑さ AI Agentで生成 (他サービスで置き換えが可能 ) 生成AIを活用してドメインを整理して、区切られた文脈や、ドメインモデリングを用意、実装を行う AI Agentで積極的にコードを生成する

Slide 46

Slide 46 text

● 中核の業務領域では抽出した用語をもとに Entity、Value Object、Aggregate Root、UseCaseを整理、実装する ● 一般・補完の業務領域ではAI Agent(Claude Code、Codex、 Gemini CLI)活用する。またアーキテクトに関わるドキュメントを用意して、生成するファイルの統一性をもたせるドメイン駆動設計における生成 AIの活用例②

Slide 47

Slide 47 text

まとめ

Slide 48

Slide 48 text

● AI時代におけるドメイン駆動設計（DDD）は、生成AIの活用によって、仕様書・会話ログ・議事録などからドメイン知識を抽出し、ドメインモデリングの土台が整いやすくなった。 ● 一方でまだまだ「中核の業務領域」においては人の判断は必要なので、それぞれの業務領域で生成AIうまく活用するのが大事だと感じています!

Slide 49

Slide 49 text

“ビジネス要求は変わり続け、優先度の変更もしょっちゅうです。しかもすべては「できるだけ速く」です。そして、研究開発をする余裕はほとんどありません。このような状況でドメイン駆動設計を受け入れる事で、私たちはさまざまな複雑さに立ち向かい、事業に貢献するソフトウェアを生み出し続ける事ができました。つまり、振り返ってみれば、ドメイン駆動設計に賭けた私たちは十分な見返りを手に入れたのです。 ”

Slide 50

Slide 50 text

ご清聴ありがとうございました ! 🍜

Slide 51

Slide 51 text

● 「ドメイン駆動設計をはじめよう」を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 参考文献