花園

8 則筆記正在生長。清除篩選 ✕

• 支援矩陣收斂史：告別 MySQL 與 SQLite 的決策帳 基底範本最初的野心是「三種資料庫都支援」：postgres、mysql、sqlite。半年後我把矩陣收斂成 postgres only——這篇記下這筆決策帳，因為「刪掉支援」比「增加支援」難談，也更值得談。 MySQL 先退場 翻遍部署紀錄：從來沒有一個場景真的用 mysql，driver 甚至沒安裝過。它卻在真實地收…⇄ 2#架構 #資料庫 #心路 最後照顧 07-14
• 自動儲存 vs 稽核紀錄：折疊窗口的取捨 後台的每個寫入端點都掛稽核——誰、什麼時候、對誰、做了什麼成功的操作，一列一筆。這套機制撞上筆記編輯器的自動儲存時，出了一個好問題：打字停頓 1.5 秒就存一次，寫一小時的文章＝幾百筆「編輯筆記」稽核，其他真正重要的動作（發佈、刪除）全被洗掉了。 選項與抉擇 不記編輯？那「已發佈的文章事後被改過」這種真正有稽核價值的事…⇄ 4#nestjs #平台 #架構 最後照顧 07-14
• Wikilinks 與 backlinks：用算的，還是落表？答案是一半一半 花園的靈魂是 雙向連結——我在筆記裡寫 某篇的slug，那篇筆記的頁尾自動長出「誰連到我」。實作上第一個要回答的問題：backlinks 是算出來的還是存起來的？ 第一版：純用算的 語法解析是 domain 的純函式：從 body 抽出所有 wikilink slug。backlinks 就是反向索引——把所有已發佈筆…⇄ 3#rootnote #ddd #架構 最後照顧 07-14
• 一個事件、三個出口：通知系統的解耦練習 平台有三個長得很像的模組：站內通知（DB + 讀取 API）、SSE 即時推播、outbound webhook（對外部訂閱者投遞）。最初的直覺是把它們做成一個「通知服務」，provider 呼叫時指定要走哪些管道——這個直覺是錯的。 正確的形狀：producer 只派發領域事件，三個出口各自是 listener。 N…⇄ 4#架構 #nestjs #平台 最後照顧 07-14
• Jobs queue 兼職 transactional outbox：一張表兩個身分 每個後端遲早要回答同一題：「這個動作要呼叫外部服務，失敗了怎麼辦？」寄信、打 webhook、通知廠商——這些不能跟 HTTP request 同生共死的事，需要「enqueue + 重試 + 死信 + 可觀測」。我把它做成平台的通用積木：一張 backgroundjobs 表、一個每五秒 tick 的 worker、…⇄ 8#nestjs #架構 #平台 最後照顧 07-14
• AsyncLocalStorage 交易傳染：跨模組交易不髒手 跨模組交易是 DDD 分層最容易破功的地方。倉儲系統的一個業務動作要同時動三個模組：容器標記入庫、儲位保留、任務建立——三筆寫入必須同生共死。傳統解法是把 EntityManager 當參數一路傳下去，於是 ORM 概念滲進每一個 domain port 的簽名，四層白分了。 解法：把交易綁在異步鏈上 Node 的 A…⇄ 4#ddd #nestjs #架構 最後照顧 07-14
• 四層 DDD：domain 層一行框架都不准碰 我的每個後端模組都是同一個四層結構，而整套架構只有一條不可協商的鐵律：domain/ 是純 TypeScript，零框架依賴。NestJS 與 TypeORM 只准出現在 application 層以下。 modules/<module/ ├── domain/ entities / value-objects / e…⇄ 5#ddd #架構 #nestjs 最後照顧 07-14
• 把散落的專案熔成一座鍛造廠：monorepo 遷移記 這一切的起點是一個很樸素的痛：我有一個 NestJS + DDD 的「基底範本」，和幾個從它長出來的產品專案——倉儲管理、交易機器人。最初的管理方式是 branch-per-project：每個專案一條長壽分支，基底改了什麼，就往各分支 cherry-pick。 聽起來可行，實際上是慢性自殺。基底修一個 bug，要在三…⇄ 8#project #架構 #心路 最後照顧 07-14