領域驅動開發系列文
研究 DDD 的過程,有發現蠻多東西都非常抽象。
此系列文,是在解釋這個神秘的主題。
Search for a command to run...
研究 DDD 的過程,有發現蠻多東西都非常抽象。
此系列文,是在解釋這個神秘的主題。
No comments yet. Be the first to comment.
GAI 的時代下,近一年很流行 Vibe-coding,幾乎人人都在草率地使用 Vibe-coding 一詞來指一系列的軟體工程實踐。它指的是一種開發者不親自手打 coding,而是僅透過自然語言向 AI 描述需求(給出「方向」或「感覺」),完全放手讓 AI 代理去自動生成、拼湊出整個應用程式的開發風格。 然而,在專業的軟體工程領域,這股看似美好的「Vibe」背後,隱藏著極高的安全隱患與系統崩潰危

書本連結 前言 會挑這本書看的人,應該都是關心自己負責專案的軟體架構的人。不只希望開發的軟體能滿足客戶的明確需求,也希望能滿足可維護性(maintainability)的隱性需求,以及自己對結構與美觀習慣的要求。 要能滿足上述這些要求很難,因為專案通常不會按照計畫進行。可能變因有 deadline,最後的 API 與承諾的不同,又或者我們的設計無法很好的貼合需求的變化所需。。因此完美的架構只有在一

我們的 AIOps agent 有個很具體的問題:它會捏造 trace ID。 當 on-call 工程師問「payment service 有沒有 error trace?」,agent 有時會信心滿滿地回答「是的,見 trace a1b2c3d4...」——但這串 ID 根本不存在 Tempo 裡。工程師點進去,404。壞的不只是使用者體驗,而是這讓整個 RCA 結論失去可信度。 另一個問題是

o11y-bench 深入剖析:讓 AI 真正面對 on-call 現場 從任務設計、合成環境、Agent 架構、評分機制到報告輸出,逐一解析這個開放 benchmark 的每個組件——以及 Gemini 3 Flash Preview 的完整實測結果 先說清楚這在解決什麼問題 目前多數 LLM benchmark 測的是「知識」:模型知不知道 PromQL 的語法,知不知道什麼是 p99

臥龍神算奇術完全兵書:從兵法原理到實戰,徹底搞懂奇術機制
