流暢交付的核心是「快速交付變更」,因此應用架構必須容易、迅速地被修改——也就是擁有高度的可修改性(modifiability)。

可修改性的場景#

雖然細節依應用而異,但流暢交付對可修改性有幾個共通要求:

• 團隊能在不需要常常牽涉其他團隊做決策與實作的情況下完成變更。
• 變更要盡可能局部化於團隊自家的程式碼庫,尤其要局限於單一元件內,避免跨元件協調的複雜度與額外開銷。
• 團隊主觀感受到「修改自家子領域很直接」。

範例場景(Orders team 擁有 Order Management 與 Discounts 子領域,分別部署為 Order Service 與 Discount Service):

• 場景 A:Orders team 想修改 Order Management 中的某條業務規則,變更不需與其他團隊協調,也不必修改 Discount Service。事後團隊回報修改過程很順暢。
• 場景 B:Orders team 想在 Order Management UI 加新功能,需要修改子領域與 Order Service 的 API。多數情況下,API 變更是向後相容的,不需與其他團隊協調;團隊回報多數時間能自主工作。

可修改性需要鬆設計期耦合 + 高內聚#

高可修改性的核心,是讓架構鬆設計期耦合且內聚——這正是第 4 章的設計原則。

當架構鬆耦合且內聚:

• 變更多半局限在單一團隊擁有的、單一元件內、子領域的某一小部分。
• 緊耦合架構則相反,任何變更都容易擴散到多元件、多團隊,耗時且難以掌握。

三條提升可修改性的路徑#

1. 鬆設計期耦合提升團隊自主性

• 不同團隊擁有的子領域若鬆耦合,團隊大致能獨立工作,設計決策多半在團隊內完成,鮮少需要等待其他團隊。

2. 鬆設計期耦合讓變更不擴散到多個元件

• 當團隊擁有多個鬆耦合元件,變更通常只會影響其中一個。
• 跨元件的變更需要小心安排部署順序,執行成本高;鬆耦合則讓這類變更變得罕見。

3. 鬆設計期耦合讓子領域更易理解、更易修改

• 鬆耦合且內聚的子領域,變更通常只影響少數類別。
• 開發者能快速找出該改的地方並完成修改,自然提升整體交付速度。

可修改性是第一個要設計到位的品質屬性——若應用本身難以修改,後續的可演化性、可測試性、可部署性都會受拖累。