1 概述
1.1 关于本书
《架构整洁之道》(Clean Architecture: A Craftsman’s Guide to Software Structure and Design)是由著名的软件工程师Robert C. Martin(又称为Uncle Bob)所著。这本书提供了软件开发和架构设计的指导原则,旨在帮助开发者构建更加稳定、可维护和灵活的软件系统。
架构本质上解决软件复杂度问题,即解决控制和逻辑分离问题;所谓的控制就是对程序的流转的与业务无关的代码或者系统控制(如多线程、异步、服务发现、部署、弹性伸缩等);逻辑就是业务逻辑,解决用户问题的逻辑。控制和逻辑构成了整体的软件复杂度,有效分离控制和逻辑会让系统得到简化。
1.2 设计与架构
“架构”这个词往往使用于”高层级”的讨论中。这类讨论一般都把”底层”的实现细节排除在外。而”设计”一词,往往用来指代具体的系统底层组织结构和实现的细节。
在软件设计中,底层设计细节和高层架构信息是不可分割的。它们组成在一起,共同定义了整个软件系统,缺一不可。架构图里实际包含了所有的底层设计细节,这些细节信息共同支撑了顶层的架构设计,底层设计信息和顶层架构设计共同组成了整个软件系统的架构文档。
1.3 软件价值
- 行为价值,软件所提供的功能;也是我们常说的业务逻辑
- 架构价值,软件系统必须有足够的灵活性;灵活性则取决于系统整体状况、组件布置以及组件之间的连接方式。
问题:那么哪个维度更重要呢?
可以用艾森豪威尔矩阵来从不同阶段来回答这个问题,业务发展早期架构属于重要但是不紧急,但是如果因为架构导致业务迭代效率越来越慢,那么架构就变得重要且紧急了。
1.4 架构目标
软件架构的终极目标:用最小的人力成本来满足构建和维护该系统的需求。也是衡量软件架构优劣的标准。
2 设计原则-SOLID
SOLID 原则的主要作用就是告我们如何将数据和函数组织成“类”(这里类不是面向对象中的类),以及如何将这些类链接成未程序。SOLID原则用于指导我们如何将砖块砌成墙与房间。
- 单一职责原则(SRP):任何一个软件模块都应该只对某一类行为负责。
- 开闭原则(OCP):软件应该是易于扩展的,同时抗拒修改的。
- 里氏替换原则(LSP):子类应该能够替换掉它们的基类并且不破坏程序的正确性。
- 接口隔离原则(ISP):客户端不应该被迫依赖于它们不使用的接口。
- 依赖倒置原则(DIP):高层模块不应该依赖于低层模块,二者都应该依赖于抽象。
3 组件原则
组件是软件的部署单元,它们是作为系统部署一部分的最小的实体。(Components are the units of deployment. They are the smallest entities that can be deployed as part of a system.)。如java jar包,C++ DLL文件等。可以将多个组件链接成一个可独立可执行的文件,又或者,可以被打包成.jar、.dll或者.exe文件,并以动态加载的插件形式实现独立部署。组件原则用于指导我们将房间等合并成房子。
组件聚合原则:
- REP(he Reuse/Release Equivalence Principle)复用/发布等同原则;复用的组件能够被独立地跟踪和升级,它们应该与发布(版本控制)的单元相等同。
- CCP(The Common Closure Principle)共同闭包原则;因为相同的原因而变化的类放在一起。
- CRP(The Common Reuse Principle)共同复用原则;不要依赖不需要的东西。
案例
不拆分:
common library对于A组件而言都符合CCP和CRP原则,但是对于B组件而言,不满足CRP原则。
拆分(拆分成3个lib):
对于A组违反CCP和CRP原则,对于B组件则符合CRP原则好处。
组组件依赖问题的三原则:
- 无依赖环原则:在组件依赖关系图中不应该存在循环依赖。
- 稳定依赖原则:组件之间的依赖关系应该是从不稳定的向稳定的方向。
- 稳定抽象原则:越是稳定的组件,应该越是抽象;而不稳定的组件,则可以是更具体的。
4 整洁架构
所有的软件系统可以降解为策略与细节两部主要元素。策略体现的是软件中所有的业务规则与操作过程,因此它是系统真正的价值所在;而细节则是指那些让操作该系统的人、与其他系统以及策略进行交互,但是又本身不会影响到策略的本身的行为,如I/O设备、数据库、Web系统、服务器、框架、交互协议等。一个良好的架构设计应该围绕用例来展开,同时应该尽可能推迟和延后决定采用什么框架、数据库、web服务等。
-
关注点的分离:通过划分不同的组件和服务,使得每个部分专注于单一的职责。如分层解耦、用例解耦、源码层解耦、服务层解耦等。
-
策略与机制分离:高层策略(如业务规则)应该与低层机制(如数据库访问)分离开,这使得策略的修改不会直接影响到底层实现,反之亦然。
-
业务逻辑与UI/外部设备的分离:用户界面、数据库、Web服务器和其他外部设备或接口,它们不应该影响到核心业务逻辑的实现,这样即使外部设备发生变化,核心逻辑也能保持不变。
-
组件独立性:架构应该促成组件间独立性,同时降低组件间的耦合,以便于独立于开发、测试、部署、维护和演进。
-
架构界限:定义清晰的界限来分隔系统的不同部分,比如使用接口或抽象类创建边界,这有助于控制系统的不同部分之间的交互方式。层与层之间应该通过抽象来进行交互,避免直接依赖具体实现,以减少组件间的耦合
如下图所示,作者提出了整洁架构设计理念,有以下特点:独立于框架、可被测试、独立于UI、独立与数据库、独立于任何外部机构。
-
业务实体这一层封装整个系统的关键逻辑,一个业务实体既可以是一个带有方法的对象,也可以是一组数据结构和函数的集合。
-
用例层通常包含的是特定应用场景下的业务逻辑,这里封装并实现了整个系统的所有用例。
-
接口适配器层中通常是一组数据转换器,它们负责将数据从用例和业务实体而言最方便操作的格式,转换成外部系统(比如数据库以及Web)最方便的操作方式。
-
最外层一般由工具、数据库、Web框架等组成的。
值得说明的是:这个图只是示例,不是说架构只能分四层。
5 最后
架构师没有速成班,架构师的成功主要靠思考力提升。也就是思维提升,只有这样,才能提升你在未知环境中判断和取舍的质量,最终通过架构设计为你所在的团队或企业带来竞争优势。
参考文献
[1] 架构整洁之道-图书(中英文版)
[1] https://blog.51cto.com/xxdeelon/2506276