# DDD 之父 Eric Evans：AI 會為軟體開發帶來變革，但仍需要人類參與設計 ### DDD & LLMs - Eric Evans - DDD Europe [https://www.youtube.com/watch?v=lrSB9gEUJEQ](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 也可能走向類似的發展路徑。 他提出 **三種可能的未來情境**： 1. **AGI（超級人工智慧）統治世界** * AI 超越人類智能，取代所有工程師，甚至威脅人類生存。 * **→ 無論我們現在是否學習 AI，結果都不會改變。** 2. **LLM 最終無法突破現有能力** * AI 技術停滯，LLM 只是昙花一現，企業回歸傳統軟體開發模式。 * **→ 沒有投入 AI 研究的人，依然可以持續做原本的工作。** 3. **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 調整效果有限，解法是： 1. **第一層 LLM（Guardrails）**：檢查對話是否符合遊戲世界觀，判斷是否合理。 2. **第二層 LLM（對話生成）**：在符合背景設定的前提下，產生合適的回應。 這個方法不僅讓 LLM 的行為更可控，也讓設計更符合 **DDD 架構設計的「關注點分離」原則**。 ![image](https://camo.githubusercontent.com/7d041f30d4ae55db019b97346b24a00e797b5c6ef1113b86dd79261b6688e716/68747470733a2f2f7265732e63726166742e646f2f757365722f66756c6c2f61616436346137642d346235662d333065632d323334302d6265386236633961316339612f646f632f35363245363142442d323143412d343635392d393439362d3243374437394243373533352f45304145463043382d303444312d343430422d383539302d3443383143413631334135375f322f6e4b6465477339796f6949496e7972574c6a79764c474956776f494a3879626d4f4a5232736e78763478387a2f496d6167652e706e67 align="left") *當玩家輸入文字後，會先經過「Guardrails (護欄）」判斷文字是否合理。如果合理，才會進到對話產生器。* ![image](https://camo.githubusercontent.com/20d6146cece8183b6d95051c3ada1c66bb106928dc16dbfb56d19862d550d642/68747470733a2f2f7265732e63726166742e646f2f757365722f66756c6c2f61616436346137642d346235662d333065632d323334302d6265386236633961316339612f646f632f35363245363142442d323143412d343635392d393439362d3243374437394243373533352f35303333343332442d463641452d343531302d423931312d3246333430443142314544335f322f684e6d575578414a774d566f63746b6e7651686275463847546d69746e324154727657617a6a68507272517a2f496d6167652e706e67 align="left") *如果玩家輸入的文字不合理，會被 Guardrails 先擋住，然後啓動另一條分支或是改變系統狀態（玩家評價降低）* ## 在 LLM 時代，DDD 或許依然實用 DDD 的核心是**處理軟體的複雜性**，而 LLM 的本質也是處理語言與知識的複雜性，因此兩者具有高度契合性。 Eric Evans 提到，他會使用 **DDD 新技術檢查清單** 來評估技術是否適合 DDD： 1. **DDD 是否能幫助我們使用 LLM？** 2. **LLM 是否能幫助我們做 DDD？** 3. **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）」** 模型： 1. **初始 Domain Model**：只有「正面回應」與「負面回應」兩類。 2. **LLM 分類結果**：發現許多回應無法準確分類，如「需要更多資訊」或「不確定」的語句。 3. **Domain Model 反向調整**：擴展為「正面 / 負面 / 中立 / 猶豫」等類別，改善分類邏輯。 4. **影響 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 共同進化**！ 🚀 ![image](https://camo.githubusercontent.com/2dd3de95a7ee439c365535be331a1db44d5793be48562fb67d0458211f5f0af5/68747470733a2f2f7265732e63726166742e646f2f757365722f66756c6c2f61616436346137642d346235662d333065632d323334302d6265386236633961316339612f646f632f35363245363142442d323143412d343635392d393439362d3243374437394243373533352f39344334393335312d334530442d343631462d414341452d3236433531453533394439445f322f79796b4d3666775546747a387a4852654b58434d4a796659384f5565447431794f5a657a473742664c34737a2f496d6167652e706e67 align="left") ## **結語：動手做，從實驗中學習** Eric Evans 強調：「**學習 LLM 最好的方式，就是動手嘗試！**」 他分享了自己的 Fine-tuning（微調）實驗不斷嘗試與犯錯的過程： * 使用了 LoRA（Low-Rank Adaptation）技術對 LLM（Mistral 7B）進行 Fine-tuning，並採用了 Hugging Face 提供的聊天資料集（[lmsys-chat-1m](https://huggingface.co/datasets/lmsys/lmsys-chat-1m)）作為訓練數據。 * 結果發現，LLM 會**投機取巧**，例如只根據輸入文字長度來分類，而不是真正理解內容。 * 這讓他意識到：**Fine-tuning 仍然需要良好的資料與驗證機制，否則容易出錯。** 最後，他鼓勵開發者：「**不要擔心失敗，多做實驗、與社群分享成果，這才是學習 AI 最好的方式！**」 **現在的 AI 研究，就像 90 年代的 Web 技術，充滿無限可能，甚至可能現在檯面上的應用都還遠遠還沒觸及所有可能性。別只滿足於當個旁觀者，趕快動手試試吧！」** --- ## Curator ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1740790098423/663bfcc4-4015-415a-8d54-18707857780e.jpeg align="left") ### Fong Syuan Liou Appier Senior Software Engineer。從 2019 年開始擔任 DDDTW 志工，曾參加過多場社群演講與工作坊主持，也寫過 ITHOME 鐵人賽得獎文章 《 Think in GraphQL 》以及 《 Think in DDD》。 喜歡 DDD 是因爲陶醉於那如散文般易讀的程式碼，卻又同時有條理地各司其職。加入社群是因爲相信分享就是最好的學習！