写点什么

利用依赖结构矩阵管理架构债务

作者:俞凡
  • 2024-05-31
    上海
  • 本文字数:1329 字

    阅读完需:约 4 分钟

本文讨论了如何利用依赖结构矩阵(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 仓库中查看源代码。如你所见,该项目由三个基础包构成:apicoredatabase,采用分层模式。api负责向外部调用者公开 restful API,core包含内部所有与业务相关的代码,而database则专注于数据库层。



在研究了现金流应用程序的 UML 图之后,我们来生成系统的依赖结构矩阵(Dependency Structure Matrix)。我通过 Jarchitect 工具生成矩阵,但此外还有很多替代方法:如 Intellij 或 NdependDSM 支持。列和行代表 Spring Boot 应用程序 src 文件夹中的 Java 类,它们的结构是对称的。第 8 列是 IncomeService,与第 8 行对应的是相同的类/接口。单元格中的数字表示类之间的静态依赖导入。例如第 12 列(ConverterServiceImpl.java)在第 4/5/10 行中标了 1,表示该类实现了 ConverterServiceExpenseConverterServiceService.



为了通过 DSM 找到架构债务,人们应该寻找:


  • 循环调用:A 类调用 B 类,B 类调用 A 类

  • 交叉:数字大的单元格意味着依赖关系多

  • 数字应围绕对角线分配:意味着类具有很强的内凝性

  • 矩阵中的数字越混乱,意味着依赖结构越不安全

  • 评估 S.O.L.I.D 原则,研究持有接口的列数




你好,我是俞凡,在 Motorola 做过研发,现在在 Mavenir 做技术工作,对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI 等技术始终保持着浓厚的兴趣,平时喜欢阅读、思考,相信持续学习、终身成长,欢迎一起交流学习。为了方便大家以后能第一时间看到文章,请朋友们关注公众号"DeepNoMind",并设个星标吧,如果能一键三连(转发、点赞、在看),则能给我带来更多的支持和动力,激励我持续写下去,和大家共同成长进步!

发布于: 12 分钟前阅读数: 5
用户头像

俞凡

关注

公众号:DeepNoMind 2017-10-18 加入

俞凡,Mavenir Systems研发总监,关注高可用架构、高性能服务、5G、人工智能、区块链、DevOps、Agile等。公众号:DeepNoMind

评论

发布
暂无评论
利用依赖结构矩阵管理架构债务_架构_俞凡_InfoQ写作社区