开闭原则包含以下两层含义:

  1. 模块的业务要稳定

每一个模块都应该是可完成的

  1. 根据模块的复杂度来决定。简单的通过回调或者接口的方式开放出去,复杂的通过插件机制将系统分解成“最小化的核心系统和多个正交分解的周边系统”事实上回调函数或者接口本质上就是一种 事件监听机制 ,所以它是插件机制的特例。

并不是这些架构设计原则不好,它们之中不乏精彩绝伦、振聋发聩的总结。比如:

  • 接口隔离原则
  • 依赖倒置原则
  • 无环依赖原则
  • 组合 / 聚合复用原则
  • 高内聚与低耦合
  • 惯例优于配置
  • 命令查询分离
  • 关注点分离

我们需要意识到的一点是,熟读架构思维并不足以让我们成为优秀的架构师。

我们做的是软件工程。软件工程的复杂性它自然存在,不会因为好的架构思维而消除。

架构师的武器库是什么?

“开闭原则” 推崇模块业务 “只读” 的思想,是很好的架构治理哲学。它告诉我们,软件是可以以 “搭积木” 的方式搭出来的。

架构分解中有两大难题

  1. 需求的交织。不同需求混杂在一起,也就是存在所谓的全局性功能
  2. 需求的易变。不同客户,不同场景下需求看起来很不一样,场景呈发散趋势。

架构师需要有自己的信仰。我们需要坚持对业务进行正交分解的信念,要坚持不断地探索各类需求的架构分解方法。

架构师的真功夫

  1. 信息科技形成的基础架构。努力把前辈们的心血,变成我们自己真正的积累
  2. 基础架构完全融入自己的思维体系,同频共振,我们才有可能在架构设计需要的时候 “想到它们”。

基础架构包含哪些内容

  1. 基础平台。包括:冯·诺依曼体系、编程语言、操作系统
  2. 桌面开发平台。包括:窗口系统、GDI 系统、浏览器与小程序 MVC架构
  3. 服务端开发平台。包括:负载均衡、各类存储中间件。服务端业务开发的业务逻辑比桌面要简单得多。服务端难在如何形成有效的基础架构,其中大部分是存储中间件
  4. 服务治理平台。主要是以容器技术为核心的 DCOS(数据中心操作系统),以及围绕它形成的整个服务治理生态

消化基础架构的过程,同时也是消化架构思维的过程。

把虚的事情往实里做,才有可能真正做好。

业务只能靠你自己的架构设计能力去构建它。而这,其实也是架构师的乐趣所在

从完整性讲,我们的架构课并没有包括所有的基础架构。
从企业的业务运营角度来说,这还远不是全部

标签: 架构, 模块, 系统, 周边, 核心, 功能, 业务, 接口, 分解, 机制, 原则, 依赖

知识共享许可协议
本作品采用知识共享署名-非商业性使用-禁止演绎 4.0 国际许可协议进行许可。

发送一条友善的评论

  • 目录