核心支撐與通用子領域的 AI 投資決策
🔖標籤 #ddd #ddd思考 #ai
[!AI] 本文摘要
導入 AI 服務前,先釐清功能隸屬的子領域類型。通用子領域是已解決的問題,適合直接採用現成方案;支撐子領域不具備競爭優勢但需客製,可用低程式碼快速建置;核心子領域才是企業護城河,值得投入深入建模。本文以領域驅動設計的子領域分類為框架,探討如何決定哪些功能該自行開發、哪些該購買,以及哪些該交給 AI 服務,協助團隊把資源投注在真正能創造價值的地方。
🔖標籤 #ddd #ddd思考 #ai
[!AI] 本文摘要
導入 AI 服務前,先釐清功能隸屬的子領域類型。通用子領域是已解決的問題,適合直接採用現成方案;支撐子領域不具備競爭優勢但需客製,可用低程式碼快速建置;核心子領域才是企業護城河,值得投入深入建模。本文以領域驅動設計的子領域分類為框架,探討如何決定哪些功能該自行開發、哪些該購買,以及哪些該交給 AI 服務,協助團隊把資源投注在真正能創造價值的地方。
🔖標籤 #ddd #ddd思考 #ai
[!AI] 本文摘要
延續角色構造型概念,本文將六種職責角色對照 AI agent 常見元件,檢查程式是否職責混雜。責任驅動設計強調物件應扮演服務提供者、資訊持有者等角色,此原則同樣適用於大語言模型代理架構。我們將記憶、工具、規劃、對話狀態與對外介面逐一映射到角色構造型,整理成一份審查清單,協助你在設計代理時分散控制權、避免元件承擔過多職責,並提供可直接執行的架構改善建議。
🔖標籤 #ddd #ddd思考 #ai
[!AI] 本文摘要
大型語言模型供應商的 API 形狀、參數與計價方式經常變動,若應用程式的領域層直接依賴這些外部規格,將導致模型詞彙滲透並扭曲核心設計。本文從限界上下文與上下文映射的角度,說明為何應將模型供應商視為外部限界上下文,並透過防腐層吸收回應格式、參數與錯誤差異,讓領域層維持純淨,最後給出可直接落實的架構建議。
🔖標籤 #ddd #ddd思考 #ai
[!AI] 本文摘要
領域驅動設計的聚合是保護業務不變量的邊界,Milan Jovanović 在文中整理了 Vaughn Vernon 提出的四條設計規則。AI 生成程式碼經常把跨聚合的狀態修改直接寫進應用服務,並將業務規則塞入服務層,導致貧血模型。本文對照四條規則與常見違規樣貌,並給出讓 AI 正確生成聚合的約束條件。
🔖標籤 #ddd #ddd思考 #ai
[!AI] 本文摘要
事件風暴(Event Storming)工作坊結束後,牆上留下大量領域事件、命令與聚合候選的便利貼。把這些便利貼交給 AI 整理成結構化清單,可以加速後續的建模工作。然而 AI 的角色僅限於提出候選,真正的聚合邊界與交易一致性判斷仍須由人決定。本文探討如何將工作坊產出餵給 AI、AI 最容易整理錯的地方,以及人機分工的實務建議。