Lou Stack Base

我原本以為把 shared logic 抽成 reusable workflows 會比較乾淨。

結果實際做完之後, 我最後把它們又收回到入口 workflows, 只保留 composite actions。不是因為 reusable workflows 不能用, 而是因為它在這個 case 裡, 沒有帶來我真正想要的「乾淨」。

如果要把 GitHub Actions 接到 GCP, 我現在最不想再做的就是:

• one shared deploy service account
• one broad trust rule
• one workflow that can hit every environment

這樣一開始很省事, 但後面只要開始切 dev / prod, 風險和 debug 成本都會一起上升。

這篇整理我最後收斂出來的做法: 用 branch、workflow、service account 三層一起切最小權限。

這篇記錄一件我現在很常回頭看的事: 如果一開始 Terraform 只有一個 root, 後來才想補 dev / prod、補 shared 層、補 CI/CD 邊界, 到底該怎麼遷移才不會影響既有環境。

我最後的結論很簡單:

這篇記錄我把一套 Cloud Run + Cloud SQL 應用留在同一個 GCP project 裡, 但仍然把 dev 和 prod 切乾淨的做法。

重點不是 branch 命名, 也不是多建兩個 GitHub workflow 而已。真正要切的是 state、資源命名、secrets、執行身分、部署身分, 還有 workflow 控管。這幾層如果只漏一層, 最後就還是會互撞。

上一篇 講了 DDD 的概念跟 .NET MVC 的對比。這篇記錄實際在專案裡踩到的坑: aggregate boundary 怎麼畫、double-entry ledger 怎麼設計、event system 怎麼讓模組之間溝通

Aggregate Boundary 畫錯的代價

Aggregate 的規則聽起來很簡單 — 一組一定要一起存取的東西, 有一個 root entity 當入口。但實際畫 boundary 的時候, 很容易畫錯

在專案開發中第一次碰到 DDD (Domain-Driven Design)。之前寫過 .NET MVC, 也學過 Go, 發現很多概念其實跟已經知道的東西有關聯, 特別是 Repository Pattern。這篇記錄一下我怎麼從這些已有的認知去理解 DDD