AI時代のドメイン駆動設計-DDD実践におけるAI活用のあり方 / ddd-in-ai-era

こちらのイベントの登壇資料です。

AI時代xドメイン駆動設計 「良いコード/悪いコードで学ぶ設計入門」ミノ駆動氏が実践するDDDのイマ
https://offers-jp.connpass.com/event/363119/

Transcript

1. © DMM © DMM AI時代のドメイン駆動設計 DDD実践における AI活用のあり方 2025/08/19(火) 合同会社DMM.com ミノ駆動
2. © DMM 自己紹介 ミノ駆動 ( @MinoDriven ) 合同会社DMM.com プラットフォーム開発本部 第3開発部 DeveloperProductivityGroup DMMプラットフォームの設計を改善し 開発生産性向上を図るのがミッション 2
3. © DMM 著書紹介 『改訂新版 良いコード／悪いコードで学ぶ設計入門』 変更容易性の高い設計を学ぶ、 初級〜中級向け入門書 初版は12刷重版 ITエンジニア本大賞2023技術書部門大賞受賞 台湾版、韓国語版でも翻訳出版 3
4. © DMM 本LTではDDDとAIとの関係について解説します まず「DDDとはなんぞや」を目線合わせした上で AIとの関わりを解説します
5. © DMM おしながき • ドメイン駆動設計は何のため？ • 戦略的DDD　とは • 戦術的DDD　とは • 戦略的DDDとAI • 戦術的DDDとAI 5
6. © DMM ドメイン駆動設計は何のため？
7. © DMM 技術は何らかの問題を解決するためにあります
8. © DMM たとえば Webフレームワークは Webサービスの開発効率化のためにあります
9. © DMM Dockerは 環境依存を解消し どこでも一貫した実行環境を提供するためにあります
10. © DMM では ドメイン駆動設計は何のためにある？
11. © DMM ドメイン駆動設計は 事業の持続的成長のための 設計戦略＆戦術の考え方です
12. © DMM 戦略的DDD　とは
13. © DMM どれを開発すべきですか？ チームの予算もエンジニアも限られています。 この状況下で顧客がより多くのお金を落としてくれるような機能を 開発する必要があります。 以下のうち、どれを開発すべきですか？ • コモディティ化した機能 • オプション機能 • 他社が真似できない魅力的な機能 • わからないからとにかく当てずっぽうで機能開発 13
14. © DMM コアドメイン（DDDの最重要概念） • ドメイン : ソフトウェアが解決する業務領域 • コアドメイン : 差別化が図られ、競争優位性を発揮する領域 • サブドメイン : 必要ではあるがコアではない領域 • 選択と集中：コアに対して集中的に（設計も含む）開発コストを投じよ、 というのがDDDの教え • 逆にコアではない部分にまでコストかけて 重厚に設計する必要はないヨ、とも述べている 14 サブドメイン1 サブドメイン2 コアドメイン
15. © DMM コアドメインの例　みんなも考えてみよう 「ここがウリだ！」「他が真似できない！」と言えるものです 15 商品／サービス コアドメインと思わしきもの ハッピーターン ハッピーパウダー スターバックス スターバックス体験 （内装の雰囲気など） SmartHR 快適な労務管理 スプラトゥーン インクならではの多彩な戦術 Claude Code CLIならではの高い応用性
16. © DMM 16 『AI時代の『ドメイン駆動設計をはじめよう』』より引用 https://speakerdeck.com/masuda220/forkwell_library_fl_100?slide=15
17. © DMM 隔離されたコア コア用のロジックとサブ用のロジック が複雑に絡み合っていると、コアの 機能を改善しようにも変更が難しく なってしまう。 従ってコアとサブでシステムを 分離隔離する。 コアにサブの要素が入り込まないよ う徹底的に純化し、コアに特化したシ ステムにする。 17 コアドメイン サブドメインA サブドメインB コアシステム サブシステム A サブシステム B
18. © DMM 開発リソース（人、金、時間）は有限ですから 戦略（費用対効果、選択と集中）を考えて 設計方針を策定しましょう、 とするのが戦略的DDDです まずこの土台がなければDDDは始まりません
19. © DMM 戦術的DDD　とは
20. © DMM 戦術的DDD 競争優位性を発揮するコアドメインは、 常に競合他社との競争にさらされます。 そのため、より優位にするための仕組みは複雑になります。 当然内部のコードもどんどん複雑化します。 複雑なコードは変更が困難になり、開発生産性が低下してしまいます。 こうした問題を解決するのが戦術的DDDです。 ドメイン層を中心としたアーキテクチャ、ドメインモデルなどを設計し、 変更容易性の向上を図ります。 20
21. © DMM レイヤードアーキテクチャ 21 ドメイン ルール解決 ユースケース 解決 入出力変換 外界 ドメイン層 ユースケース層 コントローラ層 インフラ層 View データベース 下図はレイヤードアーキテクチャの一例（いろいろバリエーションあり）。 ドメイン関心事や技術関心事単位で関心を分離することで 変更容易性の向上を図る
22. © DMM ドメイン層 22 Repository interface Aggregate Entity ValueObject 以下、代表的な設計パターン（このパターンには限らない）を用いて ドメイン概念を整理することにより変更容易性が向上する
23. © DMM DDDとAIの関係
24. © DMM 戦略的DDDとAI • AIがあってもなくても、 利益を得る上で競争優位を考え続けることは必須。 • コアドメイン即ち競争優位の検討には、 競合他社の動向やビジネスモデル、社会情勢経済情勢など、 さまざまな変数の考慮が必要であり、不確実性がとても高い。 • 生成AIは学習内容の平均に収斂する性質がある。 つまり、競争優位の検討をAIにマルナゲしても 凡庸な答えしか返ってこない可能性大。 • 壁打ちやアイデア出しといった、一部サポートや併走に AIが使えるものと考える。 24
25. © DMM 戦術的DDDとAI • 品質について何ら指示なくAIにコードを書かせると、 変更容易性に問題のあるコードを平気で書いてくる。 • AIの高速な実装により、負債があっという間に蓄積する。 • したがってAIにコードを書かせる場合、 設計品質をコントロールできるようにしなければならない。 いくつか例を紹介する。 25
26. © DMM 契約による設計に基づく高品質テストコード実装 26 # 役割 あなたは以下の専門家である - テストコード - 契約による設計（事前条件、事後条件、不変条件） # 目的 テストコード実装 # 制約 - メソッドの事前条件、事後条件、不変条件を検証するテストであること - Given-When-Thenパターンに基づいて実装すること # テスト対象 （ここにテスト対象のメソッドを指定する）
27. © DMM 負債分析プロンプト「バグサーチャー」 ミノ駆動が開発した、高精度で負債を分析するAI用プロンプト。 コードの意図を理解した判断が可能であり、その上で変更容易性に問題の あるコードを検出する。負債のスコアリング機能や、どうリファクタリングす ればいいか設計提案する機能も備えている。 27
28. © DMM 変更容易性の高いコードをAIに書かせる 前述のバグサーチャーには、変更容易性に関するノウハウを プロンプトとして実装している。 そのため、新規にコードを書かせるのにも応用可能。 実際、機能要件のテキストとバグサーチャーのプロンプトを渡して 「この要件を満たすコードを書いて」 とAIに指示すると、変更容易性の高いコードを書いてくれる。 DDDの考え方もプロンプトとして実装済みなので、 DDD流儀のコードを高速で書かせることができる。 28
29. © DMM 以上、DDDの考え方、要点を理解することで DDDにAIをどのように活用すべきかが見えてくる そしてそれは「DDDがAIに置き換わる」というものではなく、 プロダクトの持続的成長のために 「AIの力でDDDを推進しやすくする」 というのが今後の在り方だと考える
30. © DMM ご清聴ありがとうございました