把多品牌外部服務收斂成多 App Monorepo

情境

公司當時準備推出一項新的外部服務，旗下三個品牌都需要建立自己的形象網站。

從畫面看，它們差異很大：文案不同、圖片不同、品牌色不同。

但真正進到程式碼後，我發現九成以上的 Template、Component 行為與頁面結構其實相同。

如果直接建立三套獨立專案，短期開發很快，但之後每增加一個功能，就必須同步修改三次；只要其中一套漏掉或採用不同做法，原本只是品牌差異，最後就會變成程式架構差異。

我的判斷與做法

所以我沒有把「三個品牌」直接等同成「三份程式碼」。

我先把本質相同的 Template、UI 行為與樣式邏輯整理成共享能力，把真正屬於品牌的文案、圖片、Theme 與特殊需求留成可配置或覆寫的差異點。

接著將這些品牌 Application 與共享模組集中到同一個 Nx monorepo 管理。

這樣每個品牌仍然是自己的 App，但共同能力只有一個維護來源。

形成的結果

三個品牌可以維持各自的產品樣貌，同時共享相同的工程基礎。

共通功能更新時不需要在不同 Repository 重複修改，新增品牌也不必重新複製一套網站再開始分叉。

原本可能逐漸演變成三套產品的程式碼，被維持成：

多個 App，共享一套核心能力。

留下的思考

這也是我後來越來越重視 Monorepo 的原因。

它對我來說不是「把很多 Repository 搬到同一個 Folder」而已，而是：

當多個產品其實共享同一份工程知識時，讓程式碼的結構也忠實反映這件事。

品牌可以各自演進，但本質相同的能力不應該因為部署單位不同，就產生多份 Source of Truth。