技術債務（Technical Debt）是軟件開發的熱門話題，隨著時間推移，源代碼逐漸增多，技術債務也變得越來越復雜。有很多分析技術債務的工具，基本上都專注于代碼質量。架構債務是技術債務的一部分，但由于沒有像技術債務那樣的自動化工具，因此并不容易確定。

在確定架構債務時，應研究與源代碼耦合的"架構反模式"。以下是需要確定和消除的常見架構反模式：

• 不穩定接口：這些接口通常是系統的應用程序接口或入口點，有許多依賴組件，接口的微小改動都會讓所有依賴組件頭疼不已。
• 違反模塊化原則：軟件系統應采用模塊化架構。這意味著可變更組件應架構在同一模塊中，以避免模塊間的依賴。如果一個模塊的變化對其他模塊產生了巨大影響，就應該研究這一不穩定的根本原因。
• 不健康的繼承：當超類依賴于子類或調用者類依賴于超類和子類實例時，就會出現這種情況。
• 循環依賴：例如，當組件 A 依賴于組件 B，而組件 B 又依賴于組件 C，組件 C 又依賴于組件 A，就產生了循環依賴。這種情況應通過"依賴倒置原則（Dependency Inversion Principle）"加以避免。
• 軟件包循環：多個軟件包或插件混亂的相互依賴，而不是形成等級依賴關系。
• 交叉：依賴于多個其他類的上帝類，另一方面，眾多不同的類又依賴于這個特定的類。

為了避免這些架構反模式，軟件架構師應考慮實施 S.O.L.I.D.原則、GoF 設計模式、耦合原則/組件原則。

下面是示例性現金流 Spring Boot 應用的 UML，可以在 git 倉庫[2]中查看源代碼。如你所見，該項目由三個基礎包構成：api、core、database，采用分層模式。api負責向外部調用者公開restful API，core包含內部所有與業務相關的代碼，而database則專注于數據庫層。

現金流應用程序的 UML 圖

在研究了現金流應用程序的 UML 圖之后，我們來生成系統的依賴結構矩陣（Dependency Structure Matrix）。我通過 Jarchitect[3] 工具生成矩陣，但此外還有很多替代方法：如 Intellij 或 Ndepend[4] 的 DSM[5] 支持。列和行代表 Spring Boot 應用程序 src 文件夾中的 Java 類，它們的結構是對稱的。第 8 列是 IncomeService，與第 8 行對應的是相同的類/接口。單元格中的數字表示類之間的靜態依賴導入。例如第 12 列（ConverterServiceImpl.java）在第4/5/10行中標了1，表示該類實現了 ConverterService、ExpenseConverterService、Service.

現金流應用的依賴結構矩陣

為了通過 DSM 找到架構債務，人們應該尋找：

• 循環調用：A 類調用 B 類，B 類調用 A 類
• 交叉：數字大的單元格意味著依賴關系多
• 數字應圍繞對角線分配：意味著類具有很強的內凝性
• 矩陣中的數字越混亂，意味著依賴結構越不安全
• 評估 S.O.L.I.D 原則，研究持有接口的列數

參考資料：

• [1]Managing Architecture Debt with Dependency Structure Matrix:https://readmedium.com/51f63b6efb4c
• [2]SOLID Principles Sample: https://github.com/alizeynalli90/solid-principles
• [3]Jarchitect: https://www.jarchitect.com
• [4]Ndepend: https://www.ndepend.com
• [5]DSM: https://www.jetbrains.com/help/idea/dsm-analysis.html