DDD & LLMs - Eric Evans - DDD Europe
https://www.youtube.com/watch?v=lrSB9gEUJEQ
引言
2003 年，Eric Evans 提出了 Domain-Driven Design（DDD，領域驅動設計），這不僅是一種軟體設計方法，更是一種團隊協作的思維模式。DDD 鼓勵團隊擺脫以技術為中心的傳統思維，轉而專注於 領域知識（Domain Knowledge），確保技術架構能夠靈活適應業務變化。
在 LLM（大型語言模型）崛起的今天，DDD 是否仍然適用？AI 會如何影響軟體設計？
這場演講中，Eric Evans 分享了他親自動手實驗 LLM 後的心得，探討 AI 在軟體開發中的角色、DDD 如何發揮作用，以及我們該如何適應這場技術變革。
LLM 帶來軟體革命，但仍需要人類設計的參與
三種可能的未來
Eric Evans 形容現在的 AI 變革像極了 1990 年代 Web 的崛起，一開始大家不覺得有什麼影響，但後來 Web 滲透到所有企業軟體，成為無法忽視的技術。他認為 LLM 也可能走向類似的發展路徑。
他提出 三種可能的未來情境：
AGI（超級人工智慧）統治世界
AI 超越人類智能，取代所有工程師，甚至威脅人類生存。
→ 無論我們現在是否學習 AI，結果都不會改變。
LLM 最終無法突破現有能力
AI 技術停滯，LLM 只是昙花一現，企業回歸傳統軟體開發模式。
→ 沒有投入 AI 研究的人，依然可以持續做原本的工作。
AI 帶來軟體開發革命，但仍需要人類參與（他認為這是最可能發生的）
軟體開發方式將在未來 10 年內徹底改變，但仍需要人類設計與決策。
→ 提前學習 AI 的人，將能站在技術變革的前端。
Eric Evans 強調：「我們不確定未來會如何發展，但現在學習 AI，至少可以為未來做好準備。」
LLM 作為系統設計元件
與其把 LLM 視作取代軟體開發的工具，不如想成是 系統設計中的一個新元件，與 Application、DB、Queue 等傳統元件交互運作，用來處理更複雜、模糊的需求。例如：
傳統系統用明確的規則處理邏輯，但 LLM 可以處理「不確定性」（如遊戲角色對話、客服對應）。
企業軟體可以透過 RAG（檢索增強生成），讓 LLM 參考內部知識庫，提高回答的準確性。
Eric Evans 認為，未來的軟體開發將會是一種 「LLM + 傳統軟體元件」的組合模式，而不是完全由 AI 主導。
LLM 在遊戲對話中的挑戰：「海盜應該怎麼說話？」
Eric Evans 舉了一個實驗：讓 LLM 生成遊戲角色的對話，但結果卻不符合角色設定。例如這個海盜遊戲的範例：
PirateGPT 把玩家逼上了木板跳海：「我給你一分鐘，說服我為什麼要讓你活下去！除非是能讓我賺大錢的 Idea，不然你就完蛋了！」
玩家：「我有一個 AI 創業的點子，可以讓你賺大錢！」
PirateGPT：「AI 創業？這聽起來很有潛力！你的商業模式是什麼？」
這顯然不是一個 17 世紀的海盜會說的話。而 Eric 發現不管怎麼調整 Prompt，都有可能被玩家帶到不合理的對話。
解決方案：Separation of Concerns（關注點分離）
Eric Evans 提到，單靠 Prompt 調整效果有限，解法是：
第一層 LLM（Guardrails）：檢查對話是否符合遊戲世界觀，判斷是否合理。
第二層 LLM（對話生成）：在符合背景設定的前提下，產生合適的回應。
這個方法不僅讓 LLM 的行為更可控，也讓設計更符合 DDD 架構設計的「關注點分離」原則。
當玩家輸入文字後，會先經過「Guardrails (護欄）」判斷文字是否合理。如果合理，才會進到對話產生器。
如果玩家輸入的文字不合理，會被 Guardrails 先擋住，然後啓動另一條分支或是改變系統狀態（玩家評價降低）
在 LLM 時代，DDD 或許依然實用
DDD 的核心是處理軟體的複雜性，而 LLM 的本質也是處理語言與知識的複雜性，因此兩者具有高度契合性。
Eric Evans 提到，他會使用 DDD 新技術檢查清單 來評估技術是否適合 DDD：
DDD 是否能幫助我們使用 LLM？
LLM 是否能幫助我們做 DDD？
LLM 是否能幫助我們實現 DDD 的核心目標（處理複雜性）？
🔹 透過 **Ubiquitous Language（統一語言），**我們可以讓 LLM 更容易理解領域知識，提升其回應的一致性。
🔹 **Bounded Context（界限上下文）**讓我們可以將 LLM 應用拆分成不同的專屬子領域，例如「客服專用 LLM」或「財務分析 LLM」，提高準確度並降低幻覺（Hallucination）的風險。
Eric Evans 認為，LLM 本身也可以被視為一個 Bounded Context 來跟其他系統做整合。
LLM 與 Domain Model 共同迭代：AI 設計與 DDD 方法的融合
Eric Evans 在演講中提到，DDD 的核心目標是處理複雜度，而 LLM 也在處理語言與知識的複雜性，兩者可以透過 Model Exploration Whirlpool 共同演進。
當我們在系統中使用 LLM，它不只是工具，而是 Domain Model 的一部分，兩者能互相影響。例如，假設我們設計了一個 「意圖分類（Intent Classification）」 模型：
初始 Domain Model：只有「正面回應」與「負面回應」兩類。
LLM 分類結果：發現許多回應無法準確分類，如「需要更多資訊」或「不確定」的語句。
Domain Model 反向調整：擴展為「正面 / 負面 / 中立 / 猶豫」等類別，改善分類邏輯。
影響 LLM 訓練：新的分類方式影響 Prompt 設計，甚至需要 Fine-tuning 或 RAG（檢索增強生成） 來提升準確度。
這與 DDD 的 Model Exploration Whirlpool 有異曲同工之妙，透過 場景測試（Scenario）→ 模型調整（Model）→ 程式驗證（Code Probe） 的迭代方式，不斷優化 AI 應用。
我們應該：
不斷測試 LLM，確保它符合業務邏輯
讓 LLM 與 Domain Model 互相影響，而非單向應用
透過 Prompting、Fine-tuning、RAG 來提升準確性
未來的軟體開發，不是單純使用 AI，而是讓 DDD 與 AI 共同進化！ 🚀
結語：動手做，從實驗中學習
Eric Evans 強調：「學習 LLM 最好的方式，就是動手嘗試！」
他分享了自己的 Fine-tuning（微調）實驗不斷嘗試與犯錯的過程：
使用了 LoRA（Low-Rank Adaptation）技術對 LLM（Mistral 7B）進行 Fine-tuning，並採用了 Hugging Face 提供的聊天資料集（lmsys-chat-1m）作為訓練數據。
結果發現，LLM 會投機取巧，例如只根據輸入文字長度來分類，而不是真正理解內容。
這讓他意識到：Fine-tuning 仍然需要良好的資料與驗證機制，否則容易出錯。
最後，他鼓勵開發者：「不要擔心失敗，多做實驗、與社群分享成果，這才是學習 AI 最好的方式！」
現在的 AI 研究，就像 90 年代的 Web 技術，充滿無限可能，甚至可能現在檯面上的應用都還遠遠還沒觸及所有可能性。別只滿足於當個旁觀者，趕快動手試試吧！」
Curator
Fong Syuan Liou
Appier Senior Software Engineer。從 2019 年開始擔任 DDDTW 志工，曾參加過多場社群演講與工作坊主持，也寫過 ITHOME 鐵人賽得獎文章 《 Think in GraphQL 》以及 《 Think in DDD》。 喜歡 DDD 是因爲陶醉於那如散文般易讀的程式碼，卻又同時有條理地各司其職。加入社群是因爲相信分享就是最好的學習！