構建前瞻性應用架構的優秀實踐
通常，應用架構包含了所有的軟件模塊、組件、內 / 外部系統、以及構成應用之間的交互關係。顯然，結構良好的應用架構，可以確保您的應用能夠根據業務和用戶的需求進行預期的擴展。同時，好的架構既能夠合理地隔離不同的功能概念，又可以在內 / 外部形成良好的依賴關係。
那麼在實際項目中，意麪式的架構到底會給我們的系統帶來哪些危害呢?
· **服務抽象性差：**如果未能圍繞着核心業務概念，實現正確地隔離和抽象，那麼服務就會在不同系統之間分散各種業務規則，進而降低代碼的結構化和可重用的程度。
· **難以管理的依賴關係：**當組件之間無法被恰當地隔離時，任何針對系統的修改或替換操作，都會產生滾雪球式的效應。也就是說，某一部分的更改，會影響到與之相關聯的所有依賴關係。
· **僵化且運行緩慢的舊系統：**如果系統本身就很複雜且不靈活，那麼我們就需要花費更長的時間，通過調整來適應新的業務變化。而且，如果所用到的技術已經過時，那麼隨着時間的推移，核心數據與系統會對過時的技術，累積深度的依賴性，從而導致技術更新變得難上加難。
如何構建可擴展的應用架構
爲了構建可靠且可擴展的應用架構，您需要基於嚴格的定義原則和完善的設計概念。顯然，我們的目標是：既需要支持快速的業務增長和大規模的擴容需求，又需要降低部署的難度並避免高昂的代碼維護成本。因此，我們可以從如下方面考慮應用架構的設計：
· 在所有項目參與者之間達成共識。
· 支持定義和計劃。
· 持續進行變更。
· 管理好系統的複雜性。
· 管控與降低風險。
· 最大限度地減少技術債務 (這是任何前瞻性應用架構的最終目標)。
在此，我們引入一個架構畫布 (Architecture Canvas) 概念。作爲一個支持和加速架構設計的多層框架，它可以促進對可重用的服務和組件進行抽象。通過保留相對獨立的生命週期，架構畫布可以最大程度地減少變更所帶來的影響，進而使得應用架構更易於維護和擴展。
架構畫布的邏輯組成如上圖所示。其中，從下往上分別是：
**· 基礎層：**在該層中，您可以實現所有可重用的非功能性需求。例如：連接到外部系統，或者使用可重用的 UI 模式與主題庫，來擴展現有的框架服務。
· **核心層：**在該層中，您可以實現各種核心的業務服務。例如：各種圍繞着業務概念的服務、業務規則、業務實體、業務交易和業務部件等。您需要讓這些服務獨立於目標系統，並根據基礎服務來抽象出任何可能的整合信息。可見，通過基礎層和核心層，您已經隔離出了所有可重用的服務或組件。
· **最終用戶層：**在該層中，您可以通過使用基礎與核心層的服務，來支持用戶界面，以及與用戶交互的流程。值得注意的是：爲了確保整個生命週期的獨立性，處於該層面上的模塊，不應爲其他模塊提供服務。
架構的驗證
爲確保設計架構的合理性，且不會產生 “意麪式” 的爛尾，下面我將爲您提供一些可以遵循的準則和建議。
1. 不要帶有橫跨三個層面的向上引用
鑑於前文提到的結構化分層，我們顯然不應該讓與業務無關的基礎服務，去依賴核心業務; 也不應該讓可重用的服務，依賴各種最終用戶的接口。此外，向上引用往往會產生一個羣集。如下圖所示，在該羣集中，存在直接或間接鏈接關係的任何兩個模塊，都具有循環依賴性。
在上圖中，由於模塊 B 可以間接地影響模塊 A，而模塊 A 也可以間接地影響模塊 B，因此，這就是一組相互依賴的模塊。此外，如果您有另一個正在使用核心服務 B 的最終用戶模塊 (EU2)，那麼它就會依賴整個羣集。可見，它們在運行時，不僅會佔用大量不必要的資源，還會受到集羣中某些模塊變化的間接影響。
2. 避免最終用戶之間的旁路引用
爲了確保正確的隔離，並避免最終用戶具有不同的生命週期，最終用戶模塊不應提供可重用的服務。下圖展示了最終用戶之間的旁路引用關係。
也就是說，如果最終 EU1 調用到了 EU2，則表明 EU1 無法獨立於 EU2，同時他也就不能獨立於 EU2 下面的層級結構中的集羣。
3. 避免在覈心模塊和基礎模塊之間進行循環引用
如果您能夠遵循前面提到的兩個規則，那麼就不必擔心最終用戶模塊之間可能出現循環引用。反而，我們應當重點避免在覈心模塊和基礎模塊之間，可能出現的循環引用。此類模塊之間的循環引用主要產生於：一些業務概念沒能被正確地抽象，進而對代碼的管理產生不良的影響。
如上圖所示，循環引用多發生在如下兩種情況中：
· A 和 B 之間的連接相當緊密，甚至它們隸屬於同一模塊 (例如，某個訂單或訂單項)。
· 根據兩個概念之間的既定關係，如果改變一個模塊的邏輯位置，其單方面的依賴關係就會被破壞。例如，合同是由客戶產生的，但是客戶的存在則無需合同的引用。
4. 額外的建議
**核心模塊不應具有前端的篩選條件：**如果要實現某個服務，您可能需要添加一些篩選條件，用以進行單元測試。但是作爲開發人員，一旦完成了代碼測試，就應該及時去除掉測試的篩選條件。如果出於某種原因，仍需要使用測試篩選條件，來支持某些迴歸測試或 BDD(行爲驅動開發) 測試的話，您就需要將其移至最終用戶的測試模塊中。畢竟，將測試篩選條件保留在覈心模塊上，是非常危險的。基於風險管控的考慮，它們只能存在測試環境中，而不能留在生產環境裏。
**所有實體都應當被髮布爲只讀：**通過該實踐，您可以禁止訪問者 (consumers) 簡單粗暴地在數據庫中創建、更新或刪除記錄。在覈心服務層面上，您應當抽象出業務事務、驗證、規範化、以及審覈等需要與其他系統集成的組件。在實際項目中，正確的做法是：將所有的業務交易的實施，都發布給使用者，同時提供安全且恰當的抽象服務。
**避免在基礎層面上使用業務邏輯：**有時候，人們會傾向於在該層面上實現各種業務規則。但實際上，我們應當確保它與業務無關，並能在任何應用領域中被重用。
**不要在基礎層面上添加核心業務實體：**爲了與業務無關，基礎模塊不應具有與業務相關的實體。不過，它們可以通過帶有非業務的實體，以支持應用的某些非功能性需求。例如：如果您需要創建通用的服務，來審計所有事務，那麼就可以創建一個審計實體。畢竟，某個軟件應用的主要業務可能並非審計，而是銷售產品，拉新客戶或變更合同等。
這裏所說的 “應用”，與我們通常在業務環境中所提及的 “應用”，具有不同的含義。在該語境中，我們使用術語 “應用” 來指代 在開發環境中的最小部署單元。它既可以是被用於管理的所有環境，也可以是業務應用、IT 用戶、安全性集合、以及應用單個模塊等。
爲了識別應用到底屬於上面提到的哪個層級，您應該對目標應用進行深入分析和模塊化的解構。例如：如果某個應用將帶有最終用戶模塊，那麼它肯定屬於最終用戶層面。
下面是一組能夠確保設計出前瞻架構的參考規則：
規則 1：從模塊的架構畫布準則開始
我們應按照上面給出的建議，對模塊進行正確地分層。
規則 2：隔離公共服務
將各個模塊正確地放置到位後，我們就可以開始設計應用了。如前所述，如果在 “最終用戶應用 2” 上有一個模塊會使用到 “最終用戶應用 1” 上某一個模塊，那麼我們就應該對通用核心應用進行隔離，以免產生依賴性。如下圖所示，如果兩個應用要進行內容上的共享與交互，則需要在彼此隔離的情況下，通過通用的應用服務來實現。
規則 3：請勿混淆所有者角色
如果一個應用擁有多個所有者，那麼由於責任不清，可能會導致變更的內容與管理過於複雜。我們可以通過所有權的聚合與分拆 (如下圖) 兩個方式，給每個應用明確設定一個所有者。
規則 4：分清參與者角色
與所有者角色類似，參與者也有各自不同的節奏。例如：有一個提供不同保險業務的門戶網站。其所有業務線都處於同一個應用中，那麼任何一個業務 (例如車險業務) 的任何更改都不可能獨立於其他業務。因此，實際上是由那個最慢的業務線，決定了整體應用的發佈週期。
如下圖所示，我們需要通過在每條業務線中創建單獨的應用，讓每個參與者都可以預估自己的交付速度。在此基礎上，我們可以根據項目的具體需求，或是將不同參與者的任務相互隔離，或是通過內容共享的方式，加強他們的協作。
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/9AMyNJyY4vfjvlgRuWLJ2Q