🔖標籤 #ai #ai驅動開發 #coding-agent

[!AI] 本文摘要
README 寫給人看，AGENTS.md 寫給 coding agent 看，兩者目標不同。後者要的是做決定時需要的約束：建置與測試指令、禁區、命名與分層慣例、何時停下來問人。本文整理一份可直接套用的章節清單，並說明哪些內容放進去反而有害，例如過長的歷史、程式碼看得到的事、很快過期的細節，幫助團隊把 agent 正式納入開發流程。

🔖標籤 #ddd #ddd思考 #ai

[!AI] 本文摘要
請 AI 依需求寫功能時，它常把資料存取、查詢條件與狀態變更全塞進服務方法。這種做法在功能上正確，卻違反了倉儲、規格與領域事件三個戰術模式的職責分離。其中領域事件最容易被忽略，缺了它，後續要加入通知或跨聚合連動時改動成本最高。本文比較這三個模式各自解決的問題，並說明在提示中如何交代才能讓 AI 產出符合架構慣例的程式碼。

🔖標籤 #ddd #ddd思考 #ai

[!AI] 本文摘要
大型語言模型已能讀取單體系統的程式碼與資料表結構，自動提出微服務或限界上下文的候選邊界。然而，AI 的建議僅是起點，切分是否正確仍需由人員依據業務能力的獨立性、變更頻率、資料所有權與團隊邊界等判準進行驗收。本文探討如何將領域驅動設計的限界上下文概念與 AI 輔助拆分結合，說明 AI 在分析程式碼時的能力與限制，並提供一套可在實務中直接執行的驗收流程，協助團隊在舊系統現代化過程中做出更穩健的架構決策。

🔖標籤 #ddd #ddd思考 #ai

[!AI] 本文摘要
導入 AI 服務前，先釐清功能隸屬的子領域類型。通用子領域是已解決的問題，適合直接採用現成方案；支撐子領域不具備競爭優勢但需客製，可用低程式碼快速建置；核心子領域才是企業護城河，值得投入深入建模。本文以領域驅動設計的子領域分類為框架，探討如何決定哪些功能該自行開發、哪些該購買，以及哪些該交給 AI 服務，協助團隊把資源投注在真正能創造價值的地方。

🔖標籤 #ddd #ddd思考 #ai

[!AI] 本文摘要
延續角色構造型概念，本文將六種職責角色對照 AI agent 常見元件，檢查程式是否職責混雜。責任驅動設計強調物件應扮演服務提供者、資訊持有者等角色，此原則同樣適用於大語言模型代理架構。我們將記憶、工具、規劃、對話狀態與對外介面逐一映射到角色構造型，整理成一份審查清單，協助你在設計代理時分散控制權、避免元件承擔過多職責，並提供可直接執行的架構改善建議。