建立多品牌 LIFF 共用架構層

情境

Clinico 旗下不同品牌都有自己的 LINE OA 與 LIFF 服務。

從產品角度看，它們提供的業務內容不同；但實際開發後我發現，每一套 LIFF 都反覆處理非常相似的工程問題：

• 初始化 timing
• Login / Authentication
• Token 狀態
• Redirect
• LINE Browser 判斷
• 異常流程
• 頁面狀態切換

如果每個品牌各自實作，短期看起來只是幾套不同專案，但需求迭代幾次之後，同一個問題就會慢慢產生三種不同解法。

我的判斷與做法

我開始把「品牌提供什麼服務」和「LIFF 本身怎麼運作」拆成兩件事情。

品牌真正不同的業務功能繼續留在自己的 Application 裡；

而初始化、Authentication、Routing、共用頁面行為與狀態處理，則整理成一個共用的 LIFF 架構層。

同時保留可以覆寫與擴充的介面，讓不同品牌可以加入自己的特殊流程，而不需要複製整套基礎架構。

形成的結果

三套 LINE OA 可以建立在同一套 LIFF 流程模型上。

後續再增加服務時，不需要重新解一次 Login、Token、Redirect 或初始化問題；共通行為只需要維護一份，而品牌仍然保有自己的業務差異。

留下的思考

這段經驗讓我開始更明確區分：

產品差異，不代表工程基礎也必須跟著分叉。

當一個平台的基本行為本質相同，就應該只有一份真正描述它如何運作的來源。

品牌可以有很多個，但 LIFF 的 Login、Routing、Token 與初始化規則，不需要因此存在很多個版本。