利用依赖结构矩阵管理架构债务
本文讨论了如何利用依赖结构矩阵(DSM,Dependency Structure Matrix)管理和识别架构债务,并通过示例应用展示了这一过程。原文: Managing Architecture Debt with Dependency Structure Matrix
![](https://static001.geekbang.org/infoq/95/9591f386c8dad851660f6394343f9e82.png)
技术债务(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
则专注于数据库层。
![](https://static001.geekbang.org/infoq/8f/8ff971b926d5d2e26a961cfa76d2e883.png)
在研究了现金流应用程序的 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
.
![](https://static001.geekbang.org/infoq/4e/4e0e4939a9c9582cb09ff2456e8ee88f.png)
为了通过 DSM 找到架构债务,人们应该寻找:
循环调用:A 类调用 B 类,B 类调用 A 类
交叉:数字大的单元格意味着依赖关系多
数字应围绕对角线分配:意味着类具有很强的内凝性
矩阵中的数字越混乱,意味着依赖结构越不安全
评估 S.O.L.I.D 原则,研究持有接口的列数
你好,我是俞凡,在 Motorola 做过研发,现在在 Mavenir 做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。为了方便大家以后能第一时间看到文章,请朋友们关注公众号"DeepNoMind",并设个星标吧,如果能一键三连(转发、点赞、在看),则能给我带来更多的支持和动力,激励我持续写下去,和大家共同成长进步!
版权声明: 本文为 InfoQ 作者【俞凡】的原创文章。
原文链接:【http://xie.infoq.cn/article/f28433b3cacca8faa99d0cd72】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论