许式伟的架构课
许式伟
七牛云 CEO
84946 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 89 讲
许式伟的架构课
15
15
1.0x
00:00/00:00
登录|注册

58 | 如何判断架构设计的优劣?

判断模块间的耦合度是复杂的
耦合度测量公式明确了架构设计的价值主张
伤害值评估核心系统的纯洁度
架构设计的基本准则指明了方向
模块的耦合度测量公式
接口与业务的匹配性
模块实现的质量
模块接口的质量
降低添加新功能对核心系统的影响
周边功能对核心系统的影响
核心系统构成了业务的最小功能集
正交分解是对系统进行分解的过程
优先考虑组合而不是继承
环境模拟是模块测试的需要
可测试性为设计目标
低耦合
模块的规格比实现机制重要
着眼于模块而不是框架
接口语义要自然
避免过度设计
简单就是美
Orthogonal Decomposition:正交分解
Testable:保证可测试性
Modularity:着眼于模块而不是框架
KISS:简单比复杂好
结语
模块的耦合度测量
核心系统的伤害值
Orthogonal Decomposition
Testable
Modularity
KISS
架构设计的基本准则
如何判断架构设计的优劣?

该思维导图由 AI 生成,仅供参考

你好,我是七牛云许式伟。
想要让自己进步,我们首先得知道什么是好的。所以我们今天的话题是,如何判断架构设计的优劣?

架构设计的基本准则

架构设计会有它的一些基本准则。比如:
KISS:简单比复杂好;
Modularity:着眼于模块而不是框架;
Testable:保证可测试性;
Orthogonal Decomposition:正交分解。
KISS 全称是 Keep it Simple, Stupid,用最直白的话说,“简单就是美”。不增加无谓的复杂性。正确理解系统的需求之后才进行设计。要避免过度设计,除非有人为复杂性买单。
KISS 的“简单”,强调的是易实施性。让模块容易实现,实现的时候心智负担低,比复杂的优化更重要。
KISS 的“简单”,也是主张让你的代码,包括接口,符合惯例。接口语义要自然,最好让人一看方法名就知道怎么回事,避免惊异。
Modularity,强调的是模块化。从架构设计角度来说,模块的规格,也就是模块的接口,比模块的实现机制更重要。
我们应着眼于模块而不是框架。框架是易变的。框架是业务流,可复用性相对更低。框架都将经历不断发展演化的过程,逐步得到完善。
所以不让模块为框架买单。模块设计时应忽略框架的存在。认真审视模块的接口,发现其中“过度的(或多余的)” 约束条件,把它提高到足够通用的、普适的场景来看。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

架构设计的优劣如何判断?本文从KISS、Modularity、Testable和Orthogonal Decomposition四个基本准则出发,强调简单性、模块化、可测试性和正交分解。文章指出,核心系统构成了业务的最小功能集,对核心系统的变更要额外小心,而周边功能的添加应尽可能降低对核心系统的影响。作者提出了一个经验公式来衡量周边功能对核心系统的总伤害,强调修改处数越多,伤害越大。文章还提到了定性和定量的质量判定方法,但指出目前并没有听说过任何定量的判断方法来确定架构设计的优劣。文章内容深入浅出,为读者提供了架构设计质量评估的方法和思路。 文章主要讨论了如何评判架构设计的优劣。首先介绍了架构设计的基本准则,强调了简单性、模块化、可测试性和正交分解的重要性。随后提出了一个经验公式来衡量周边功能对核心系统的总伤害,强调了修改处数越多,伤害越大。此外,还介绍了模块的耦合度测量公式,强调了对外部成熟模块的鼓励和对耦合度测量公式的理解。最后,指出了耦合度测量公式的局限性,提出了对动态依赖的考虑,并展望了下一讲的话题。整体而言,本文为读者提供了架构设计质量评估的方法和思路,具有一定的实用性和指导意义。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《许式伟的架构课》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(16)

  • 最新
  • 精选
  • Bachue Zhou
    其实还有一种耦合度经常被人忽视,就是技术耦合度。我们相信,无论是今天多么流行的技术,未来都有失去竞争力的一天,但要开一家长达数十年甚至数百年的技术公司,不可能长期使用已经失去竞争力的技术,必然涉及到技术的多次演进。如果公司的关键性产品与某一种技术耦合度太高,则当该技术失去竞争力或彻底淘汰后,技术迁移成本过高,极易造成迁移彻底失败。所以我从不看好那种一个 Git 库里数十万甚至数百万行 xx 语言或者基于 xx 框架编写的代码,要起一个新项目还必须去引用这个库里的代码不可,这种项目不可能活很久。如果这个项目是公司的关键性产品,那么这个公司也活不了很久。

    作者回复: 👍

    2019-11-22
    8
    34
  • Geek_03056e
    两个核心模块之间由接口调用,并且是A调用B这种的单方面调用,可是两个模块有公用的结构体数据,这些结构体的定义,应该放到那个位置呢?

    作者回复: 如果认为B更加基础、可以放在B。也有人会放在单独的C。anyway,如果A、B、C都隶属于核心系统,全局来说放在哪里只是个细节,对外来说没区别,只不过最好有一个总的入口级模块D把所有这些模块组装起来形成一个整体的DOM。

    2019-11-20
    2
    6
  • 亢(知行合一的路上)
    * 模块的规格,也就是接口,比模块的实现机制更重要。 * 接口是抽象的,比较稳定的,与具体实现无关,实现可以不断优化,但接口不变。因此与外部模块的关系就是稳定的,整个系统就是稳定的。 * 不让模块为框架买单,框架是业务流,可复用性相对更低。 * 业务是易变的,框架也是易变的。 * 不同项目或产品,业务相差很大,框架也就各异。 * 不同项目是不是会使用一些通用的模块呢? * 例如缓存功能,不关心缓存的是什么; * 限流,也不关心业务内容; * 模块设计时,要尽可能和业务解耦,提供抽象的接口。 * 老师把架构设计的质量评估表述成公式,很有意义,为我们提供了判断依据。

    作者回复: 引用的通用模块越多,越多既有成熟的老模块,代表架构越强大。

    2020-04-25
    3
  • Tesla
    我是这样想的,极客时间的核心是知识,学生是知识的订阅者,老师是知识的发布者。但是知识的形式又是多样化的,所以知识本身也需要抽象。 设计出来的核心数据结构是,保留知识基本信息及类型ID的类,用户类,用户发布知识的权限类,用户订阅知识的权限类,用户余额类。核心接口是用户注册接口,余额增加 减少接口,发布知识接口,订阅知识接口,判断是否有权添加 修改知识的接口,判断是否有权查阅知识的接口。 其他的功能是周边系统,有知识的具体内容类,各种订阅优惠券类等等。 不知道这样分析的思路对不对😂

    作者回复: 挺好的,我觉得基本上没有什么问题。我们在线下培训的时候会要求需求分析做足,正确的需求分析可以指导怎么做好架构。

    2020-01-28
    3
  • Tesla
    老师,可以简单说下 极客时间app的核心系统和周边系统大概是什么吗?

    作者回复: 挺好的问题。你有找到自己的答案么?

    2020-01-28
    2
  • 有米
    判断依赖的程度其实就是看它们交互的次数,无论静态或者动态

    作者回复: 是的

    2020-04-02
    1
  • tomz
    老师你好,在看你的耦合度公式,收益良多。但是不清楚为什么公式是log2()?我可以理解一定不是线性正比(因为那就意味着:n个符号各依赖1次 === 一个符号依赖n次,而显然,前者耦合性更大),但是为什么是log2()?

    作者回复: log2只是代表了对数关系,logn和log2之间是常量系数关系,所以下标不重要

    2022-05-03
  • Longerian
    生产过程中,核心系统的伤害值、模块的耦合度测量,有公司或者团队在这么定量操作吗?感觉应该要有此类插件或者代码分析工具给出近似值才行。

    作者回复: 这里的公式只是我个人的经验公式

    2020-02-23
  • @㍿社长
    想知道,动态的耦合会对系统的复杂性造成什么影响吗?

    作者回复: 动态的耦合?

    2019-12-18
  • “优先使用对象组合,而不是继承”是面向对象设计的原则之一。其中老师说的组合是乘法,继承是加法让我困惑了下。网上查了下资料《组合也叫“对象持有”,就是在类中定义另一类型的成员,继承会破坏类的独立性,增加系统的复杂性,一般系统的继承层次不超过3层。组合拥有良好的扩展性,支持动态组合,因此优先考虑组合方法。》 更清楚了些。
    2019-12-24
    6
收起评论
显示
设置
留言
16
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部