本文讨论了如何利用依赖结构矩阵（DSM，Dependency Structure Matrix）管理和识别架构债务，并通过示例应用展示了这一过程。原文: Managing Architecture Debt with Dependency Structure Matrix
技术债务（Technical Debt）是软件开发的热门话题，随着时间推移，源代码逐渐增多，技术债务也变得越来越复杂。有很多分析技术债务的工具，基本上都专注于代码质量。架构债务是技术债务的一部分，但由于没有像技术债务那样的自动化工具，因此并不容易确定。
在确定架构债务时，应研究与源代码耦合的"架构反模式"。以下是需要确定和消除的常见架构反模式：
- 不稳定接口：这些接口通常是系统的应用程序接口或入口点，有许多依赖组件，接口的微小改动都会让所有依赖组件头疼不已。
- 违反模块化原则：软件系统应采用模块化架构。这意味着可变更组件应架构在同一模块中，以避免模块间的依赖。如果一个模块的变化对其他模块产生了巨大影响，就应该研究这一不稳定的根本原因。
- 不健康的继承：当超类依赖于子类或调用者类依赖于超类和子类实例时，就会出现这种情况。
- 循环依赖：例如，当组件 A 依赖于组件 B，而组件 B 又依赖于组件 C，组件 C 又依赖于组件 A，就产生了循环依赖。这种情况应通过"依赖倒置原则（Dependency Inversion Principle）"加以避免。
- 软件包循环：多个软件包或插件混乱的相互依赖，而不是形成等级依赖关系。
- 交叉：依赖于多个其他类的上帝类，另一方面，众多不同的类又依赖于这个特定的类。
为了避免这些架构反模式，软件架构师应考虑实施 S.O.L.I.D.原则、GoF 设计模式、耦合原则/组件原则。
下面是示例性现金流 Spring Boot 应用的 UML，可以在 git 仓库中查看源代码。如你所见，该项目由三个基础包构成：api、core、database，采用分层模式。api负责向外部调用者公开restful API，core包含内部所有与业务相关的代码，而database则专注于数据库层。
在研究了现金流应用程序的 UML 图之后，我们来生成系统的依赖结构矩阵（Dependency Structure Matrix）。我通过 Jarchitect 工具生成矩阵，但此外还有很多替代方法：如 Intellij 或 Ndepend 的 DSM 支持。列和行代表 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 原则，研究持有接口的列数
你好，我是俞凡，在Motorola做过研发，现在在Mavenir做技术工作，对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣，平时喜欢阅读、思考，相信持续学习、终身成长，欢迎一起交流学习。为了方便大家以后能第一时间看到文章，请朋友们关注公众号"DeepNoMind"，并设个星标吧，如果能一键三连(转发、点赞、在看)，则能给我带来更多的支持和动力，激励我持续写下去，和大家共同成长进步！