架构设计的基本准则

KISS: 简单比复杂好
- Keep it Simple, Stupid, 不增加所谓的复杂性. 在正确理解系统的需求之后才进行设计. 要避免过度设计, 除非有人为复杂性买单.
Modularity: 着眼于模块而不是框架
- 强调模块化. 从架构设计调度来说, 模块的规格, 也就是模块的接口, 比模块的实现机制更重要.
Testable: 保证可测试性
- 强调模块的可测试性. 设计应该以可测试为第一目标. 可测试往往意味着低耦合. 一个模块可以很方便地进行测试, 那么可以说它是一个设计优秀的模块.
Orthogonal Decomposition: 正交分解
- 架构就是不断地对系统进行正交分解的过程
- 一个设计原则: “优先考虑组合, 而不是继承”, 用正交分解的角度来诠释, 它本质上是鼓励我们做乘法而不是做加法. 组合是乘法, 它是让我们用相互正交、完全没有相关性的模块, 组合出我们要的业务场景. 而继承是加法, 通过叠加能力把一个模块改造成另一个模块.
- 个人理解: 某个业务线, 需要实现功能, 那么这些功能需要由不同的服务组合完成, 将大的功能需要实现的内容分成不同的服务, 每个服务做它相关的事情(单一职责原则), 后续也便于迭代和维护

核心系统的伤害值

正交分解, 第一件事就是要分出哪些是核心系统, 哪些是周边子系统. 核心系统构成了业务的最小功能集, 而后通过不断增加新的周边功能, 而演变成功能强大的复杂系统.

对于核心系统的变更要额外小心. 如果某新功能早期没有规划, 后期却被界定为属于核心功能, 我们就需要认真评估它对既有架构的破坏性.(个人公司项目中结算单功能)

至于周边功能, 我们核心考虑的是, 如何降低一个新的周边功能对核心系统的影响?

不论哪一种情况, 如果我们不够小心, 系统就会由于不断增加功能而变老化, 散发出臭味.

为了减少一个功能带来的负面影响, 这个功能相关代码首先要做到尽可能内聚.

核心系统越干净, 增加新功能越容易.

第二个要关注的问题, 是每个模块自身的质量. 模块自身的质量具体来说, 又包括模块接口的质量和模块实现的质量. 模块接口的是对外的, 模块实现是对内的.

模块接口的质量, 取决于以下两个方面:

此文章为3月Day23学习笔记, 内容来源于极客时间《许式伟的架构课》, 强烈推荐该课