当前位置：首页 > news >正文

架构整洁之道-读书总结

news 2025/7/19 1:44:36

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框架等组成的。
值得说明的是：这个图只是示例，不是说架构只能分四层。