Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
DDDのエッセンスを取り入れたAIでの開発
Search
ak2ie
August 19, 2026
Technology
300
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
DDDのエッセンスを取り入れたAIでの開発
AI時代のドメイン駆動設計LT会(2026/08/20)での発表内容です
ak2ie
August 19, 2026
More Decks by ak2ie
See All by ak2ie
Claude Codeはレガシー移行でどこまで使えるのか?
ak2ie
1
1.7k
SVG完全に理解してグラフ書いてみた
ak2ie
0
71
Go言語CLIツールで生産効率UPした話
ak2ie
0
130
Goではじめるバックエンド開発
ak2ie
0
91
Notion APIと学ぶNext.js
ak2ie
0
600
NestJSのはじめ方
ak2ie
0
170
フロントエンドでDDDやってみた
ak2ie
0
91
初心者がシビックテックに参加してみた
ak2ie
0
140
Firebase についてとことん語りたい
ak2ie
0
130
Other Decks in Technology
See All in Technology
2026-09-26 Platform Engineering Kaigi 2026 インフラとアプリの境界線と委譲の設計 / Drawing the Infra and App Line
masasuzu
0
500
VS Code × GitHub Copilot での Fabric 開発
ryomaru0825
1
200
個別開発で終わらせない。 現場の課題をプロダクトの強さに変える StockmarkのFDE
ktkrhr
0
440
spanner-autoscalerに学ぶ CRD設計パターン 〜自動化と緊急時対応を両立する Kubernetesコントローラーの作り方〜
tkuchiki
0
210
Databricksメトリクスビューはじめてのもくもく会
taka_aki
0
140
HolmesGPTで始めるSREエージェント入門!プラットフォームの障害調査はAIにお任せ 〜
sanghyuk
0
250
Terraformを用いたJamf Pro構成のIaC, GitOps化への挑戦
yukun
0
120
Azure Copilot Resiliency Agentをいろいろ試してみる
tomokusaba
0
140
スキルを作る、その前に!複数人で使われるスキルを 作るためのプロセス
junkifurukawa
1
120
可視化から始めたAI駆動開発_ochi_ver1.01 / AI-Driven Development Starting with Visualization_ver1.01
yayoi_dd
0
110
Account Factory for Terraformによる 標準化されたアカウント発行の自動化
pensuke628
0
120
The kernel report
ennael
PRO
1
150
Featured
See All Featured
AI Search: Where Are We & What Can We Do About It?
aleyda
0
8k
Fireside Chat
paigeccino
43
4k
Raft: Consensus for Rubyists
vanstee
142
7.7k
The Cost Of JavaScript in 2023
addyosmani
55
10k
Practical Orchestrator
shlominoach
192
12k
YesSQL, Process and Tooling at Scale
rocio
174
15k
How GitHub (no longer) Works
holman
316
150k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
840
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
3k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
3k
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
340
技術選定の審美眼(2025年版) / Understanding the Spiral of Technologies 2025 edition
twada
PRO
120
120k
Transcript
LIGHTNING TALK DDDのエッセンスを取り入れた AIでの開発 認可とワークフローの仕様を、モデルで守る 2026/08/20|AI時代のドメイン駆動設計LT会
ABOUT ME 02 自己紹介 AIを活用したWebシステム開発に取り組んでいます 名前 秋田大介 所属 株式会社メンバーズ 職種
エンジニア X @ak2ie_tech
AGENDA 03 今日お話しすること 申請システムで起きた問題から、DDDでの解決まで 01 システムの概要 認可・閲覧範囲・状態遷移 02 困ったこと 共通化しても残った課題
03 DDDでの解決 ドメインモデル/集約『申請』へ集約 04 まとめ 部分的にDDDを採用して得たこと 本日は『全部DDD』ではなく、必要な部分に使った話をします
SYSTEM OVERVIEW 04 社内の申請システム 3つのロールで操作 申請者 課長 → 下書きを作成し申請 部長
→ 申請を承認・差し戻し 課長が承認した申請を 決裁・差し戻し 課長・部長は自部署の申請のみ操作可能。兼務もある。
SYSTEM OVERVIEW 05 申請は4つのステータスを遷移する 逐次遷移と、部長による直接遷移の2つの経路がある 下書き 申請中 承認済 決裁済 一般:申請
課長:承認 部長:直接決裁 部長:決裁 完了 差し戻し 差し戻し 申請中 → 下書き:課長 承認済 → 申請中 承認済 → 下書き :部長
PROBLEM — IDEAL 06 権限マトリクスを一か所で判定すればOKと思った ロール × リソース × 操作で『見える・できる』を表す
01 ロール 一般/課長/部長 02 リソース 一般:自分が担当する申請を閲覧 課長・部長:自部署の申請を閲覧 03 操作 申請/承認/決裁/差し戻し 閲覧と操作の両方を、同じ3軸の共通ロジックで管理する
02 PROBLEM 理想どおりには、 いかなかった 共通関数を用意しても、画面・APIごとの差が残った ここから、実装で起きた3つの問題を見ていきます 07
PROBLEM — REALITY 08 共通関数があっても、使い方が共通とは限らない 未使用や誤ったカラム指定で、画面ごとの差が残った 01 関数を使わない 一部の画面・APIでは権限チェック自体が未適用 02
入力を間違える 担当者を渡すべき箇所で作成者を渡す 03 リソースの考慮漏れ 部署兼務の場合に正しく動作しないことがあった なぜ共通関数が機能しなかったのか? 判定前の『申請データの作り方』が揃っていなかった
PROBLEM 09 遷移とデータ更新も、処理ごとに差が生まれる 同じ操作でも、APIや実行経路が違うと不具合になり得る 遷移ルール 日時更新 逐次用と直接用で遷移表が別々 遷移可能ステータスに差異が発生 直接遷移時に、不要になった 操作日時のクリアが漏れた
申請API 承認API 決裁API 差戻API 判断と更新をそれぞれが持つほど、一貫性を保ちにくい
03 SOLUTION WITH DDD では、どう解決するか DDDのエッセンスを使う 分散した判断と更新を、ドメインモデル『申請』へ集める 申請を集約とし、同じ仕様を必ず通る構造へ変えます 10
SOLUTION WITH DDD 11 分散していた判断をドメインモデル『申請』へ集約した 困っていたことと対策を、一対一で対応させる 困っていたこと モデルで行う対策 関数の呼び出し漏れ →
ドメインモデルを使わないと処理できない 入力パラメータの指定誤り → 権限判定をモデル内で行う 逐次と直接で遷移可能状態が違う → 遷移表をモデルの振る舞いへ統合 直接遷移時に操作日時のクリア漏れ → 日時更新・クリアをモデル内に閉じ込める 『申請』を集約とし、整合性を守る単位の中で判断と更新を完結させる
CONCRETE EXAMPLE 12 『部長が直接決裁する』を、1つの操作で保証する APIは『申請』集約の決裁操作を呼ぶだけ。6つの条件を集約が処理する 01 ロール 部長ロールを持つか確認 04 状態遷移
決裁済へ変更 02 リソース 申請が自部署のものか確認 05 日時更新 不要な日時をクリアし決裁日時を 設定 03 操作 統合した遷移ルールで確認 個別決裁でも一括決裁でも、同じ『申請』集約を通れば条件は同じ
SUMMARY 13 判断漏れを探すより、必ず通る仕様の中心をつくる システム全体ではなく、申請部分を境界づけられたコンテキストとした 01 問題 画面・APIごとに判断材料とルールが違った 02 対策 ドメインモデル/集約『申請』へ、判断と更新を集約
03 期待する効果 同じ操作が同じ仕様を通り、レビュー箇所も絞られる 株式会社メンバーズ 採用募集中 https://career.members.co.jp/recruit/