宜昌本地网站,广州做外贸网站公司,对外宣传推广方案,适合小县城开的加盟店1 概述
1.1 关于本书
《架构整洁之道》#xff08;Clean Architecture: A Craftsman’s Guide to Software Structure and Design#xff09;是由著名的软件工程师Robert C. Martin#xff08;又称为Uncle Bob#xff09;所著。这本书提供了软件开发和架构设计的指导原则…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文件并以动态加载的插件形式实现独立部署。组件原则用于指导我们将房间等合并成房子。 组件聚合原则
REPhe Reuse/Release Equivalence Principle复用/发布等同原则复用的组件能够被独立地跟踪和升级它们应该与发布版本控制的单元相等同。CCPThe Common Closure Principle共同闭包原则因为相同的原因而变化的类放在一起。CRPThe 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
