花園

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

• 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