许式伟的架构课
许式伟
七牛云CEO
立即订阅
20237 人已学习
课程目录
已更新 75 讲 / 共 87 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (12讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
63 | 接口设计的准则
64 | 不断完善的架构范式
65 | 架构范式:文本处理
66 | 架构老化与重构
许式伟的架构课
登录|注册

64 | 不断完善的架构范式

许式伟 2019-12-13
你好,我是七牛云许式伟。
我们在 “62 | 重新认识开闭原则 (OCP)” 这一讲中介绍了开闭原则。这篇内容非常非常重要,可以说是整个架构课的灵魂。
总结来说,开闭原则包含以下两层含义:
第一,模块的业务要稳定。模块的业务遵循 “只读” 设计,如果需要变化不如把它归档,放弃掉。这种模块业务只读的思想,是架构治理的基础哲学。我平常和小伙伴们探讨模块边界的时候,经常会说这样一句话:
每一个模块都应该是可完成的。
这实际上是开闭原则的业务范畴 “只读” 的架构治理思想的另一种表述方式。
第二,模块业务的变化点,简单一点的,通过回调函数或者接口开放出去,交给其他的业务模块。复杂一点的,通过引入插件机制把系统分解为 “最小化的核心系统 + 多个彼此正交的周边系统”。事实上回调函数或者接口本质上就是一种事件监听机制,所以它是插件机制的特例。
上一讲我们介绍了接口设计。到此为止,我们的架构思维篇也已经基本接近尾声。可能有人会越来越奇怪,为什么我还是没有去聊那些大家耳熟能详的架构设计原则?
实际上,并不是这些架构设计原则不好,它们之中不乏精彩绝伦、振聋发聩的总结。比如:
接口隔离原则(Interface Segregation Principle,ISP):一个模块与另一个模块之间的依赖性,应该依赖于尽可能小的接口。
依赖倒置原则(Dependence Inversion Principle,DIP):高层模块不应该依赖于低层模块,它们应该依赖于抽象接口。
无环依赖原则(Acyclic Dependencies Principle,ADP):不要让两个模块之间出现循环依赖。怎么解除循环依赖?见上一条。
组合 / 聚合复用原则(Composition/Aggregation Reuse Principle,CARP):当要扩展功能时,优先考虑使用组合,而不是继承。
高内聚与低耦合(High Cohesion and Low Coupling,HCLC):模块内部需要做到内聚度高,模块之间需要做到耦合度低。这是判断一个模块是在做一个业务还是多个业务的依据。如果是在做同一个业务,那么它所有的代码都是内聚的,相互有较强的依赖。
惯例优于配置(Convention over Configuration,COC):灵活性会增加复杂性,所以除非这个灵活性是必须的,否则应尽量让惯例来减少配置,这样才能提高开发效率。如有可能,尽量做到 “零配置”。
命令查询分离(Command Query Separation,CQS):读写操作要分离。在定义接口方法时,要区分哪些是命令(写操作),哪些是查询(读操作),要将它们分离,而不要揉到一起。
关注点分离(Separation of Concerns,SOC):将一个复杂的问题分离为多个简单的问题,然后逐个解决这些简单的问题,那么这个复杂的问题就解决了。当然这条说了等于没说,难在如何进行分离,最终还是归结到对业务的理解上。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • Sam
    跟着许大这一路走来,让我在架构认知上得到前所未有的提高,更是不断的遵循“架构是门实践”的学课原则,不断的在工作中实践。眼看课程就要结束了,真担心在课程结束后遇到无法解决的架构难题时找不到方向,希望课程结束后还能以某种方式与老师保持联系和沟通。
    2019-12-13
    2
  • 轶名
    有种拨开云雾见月明的感觉
    2019-12-13
    1
  • 歌在云端
    买了这么多课程,感觉还是许老师的讲的最好,最有深度
    2019-12-13
    1
  • 靠人品去赢
    什么时候也能自己负责一个产品的架构,从业务上考虑但是呢还能在开闭原则上有考虑,不至于业务方向一变就要开始打补丁。

    作者回复: 加油

    2019-12-13
    1
  • 知行合一
    有深度,我理解不是很到位,感觉自己还得再从头刷一遍
    2019-12-18
  • 沫沫(美丽人生)
    许老师好。数据治理和运营体系搭建,能否先出一个1.0版本呢,一定会给这个行业带来巨大的价值。谢谢。
    2019-12-15
  • Aaron Cheung
    业务的正交分解 理论知道了很多还需要实践 补打卡
    2019-12-14
  • 梦醒十分
    出书吧!买来经常复习!适合多看几遍。
    2019-12-14
  • leslie
    许老师的课一路跟随至今除了桌面开发平台这块确实有些前端,没有去扩展;其它的基础架构不少是这些年工作中经历过然后觉得自己太浅或深度不够都进行了扩展,然后不知不觉中发现自己每个月都处在高压学习和自我总结中;年末看自己的学习课程发现突然比预计多了差不多10门,辛苦却收益满满。
          关于老师提及的两块提出一些个人的学后感:
           一块是业务:老师课程中"业务只能靠你自己的架构设计能力去构建它。"个人觉得是产品的思路刚好对应了业务角度;后期又在此进行了扩展,然后发现确实理解的更加深了。
             一块是数据:在"键值存储和数据库“提及了"中间件存储"的概念其实就是"其实就是站在数据系统的角度去思考的,当时学习就一堆反思以及进一步的把市场上数据相关的经典书籍,在某本书籍中看到了"数据系统"这个词,其实这就是数据架构层对此的解释;然后再结合《深入浅出计算机组成原理》把那两章老师的课程又学了一遍;架构同样是层层嵌套,每块都要结合软硬件层架构去思考才能理解。
        关于老师所说的“数据治理与业务运营体系构建”,个人觉得同样是基于中间件存储和数据系统去从业务层进一步去讲解;这其实就体现了老师课程中提及的"架构师需要有自己的信仰。我们需要坚持对业务进行正交分解的信念,要坚持不断地探索各类需求的架构分解方法。这样的思考多了,我们就逐步形成了各种各样的架构范式。"。
            谢谢老师辛勤的付出,虽然跟随学习的过程确实辛苦,不过收获的喜悦这其实就是IT从业者真正追求的。非常期待老师《数据治理与业务运营体系构建》课程的推出:感谢老师的分享,期待下堂课继续跟随老师学习,跟随老师进步。

    作者回复: 有付出必有回报

    2019-12-13
  • 学习这门课收获很多
    2019-12-13
  • :)
    希望老师能把这门课出本书啊!
    2019-12-13
收起评论
11
返回
顶部