架构整洁之道(架构篇)

光光-Leo 光光-Leo     2022-12-10     529

关键词:

只有顺心意,才能逆天命 --猫腻《择天记》

接上文:架构整洁之道(原则篇)

欢迎关注微信公众号“江湖喵的修炼秘籍”

1.什么是软件架构

什么是软件架构?

软件架构的实质就是规划如何将系统切分成组件,安排好组件之间的排列关系,以及组件组件之间的通信方式。

“软件架构师”的工作内容是什么?

软件架构师应该坚持做一线程序员,应该在自身承接编程任务的同时引导团队向一个能够最大化生产力的系统设计方向前进。如果架构师从代码中解放出来,就不能亲身承受因系统设计而带来的麻烦和痛苦

软件架构设计的目标?

软件架构设计的主要目标是支撑软件系统的全生命周期,设计良好的架构可以让系统便于理解,易于修改,方便维护,并且能够轻松部署。

软件架构的终极目标是最大化程序员的生产力,最小化系统的总运营成本。

以下从不同角度看待软件架构的目标:

**开发:**软件架构的作用是便于开发

**部署:**一个系统的部署成本越高,可用性越低,实现一键式的轻松部署是软件架构设计的一个目标。运用微服务架构时,要合理控制服务数量。

**维护:**系统维护成本主要集中在“探秘”和“风险”两件事情上,“探秘”的目的是确认新增功能或者被修复问题的最佳位置和最佳方式;“风险”的目的是确认再进行修改时,可能衍生出的新问题。软件架构设计的目标是降低这两个成本。

**保持可选项:**一个优秀的软件架构师应该致力于最大化的可选项数量。高层策略应该避免固化具体的实现细节,比如选择何种UI,选择哪种数据库等等,应尽可能长的延迟这种决策,保留更多的选择性。

**设备无关性:**程序应该与设备无关。

2.重复

架构师们经常会钻进一个牛角尖——害怕重复。

当然,重复在软件行业里一般来说都是坏事。我们不喜欢重复的代码,当代码真的出现重复时,我们经常会感到作为一个专业人士,自己是有责任减少或消除这种重复的。

但是重复也存在着很多种情况。其中有些是真正的重复,在这种情况下,每个实例上发生的每项变更都必须同时应用到其所有的副本上。重复的情况中也有一些是假的,或者说这种重复只是表面性的。如果有两段看起来重复的代码,它们走的是不同的演进路径,也就是说它们有着不同的变更速率和变更缘由,那么这两段代码就不是真正的重复。等我们几年后再回过头来看,可能会发现这两段代码是非常不一样的了。

当我们按用例垂直切分系统的时候,这样的问题会经常出现。我们经常遇到一些不同的用例为了上述原因被耦合在了一起。不管是因为它们展现形式类似,还是使用了相似的语法、相似的数据库查询/表结构等,总之,我们一定要小心避免陷入对任何重复都要立即消除的应激反应模式中。一定要确保这些消除动作只针对那些真正意义上的重复。

3.划分边界

一个系统中最消耗人力资源的 是系统中存在的耦合。

我们应该在软件架构中划分边界,将系统分割成组件,一部分是系统的核心业务逻辑组件,一部分是与核心业务逻辑无关但是负责提供必要功能的插件。

业务逻辑是什么

业务逻辑就是程序中那些真正用于赚钱或者省钱的业务逻辑与过程。

业务逻辑应该保持纯净,不要掺杂用户界面或者所使用的数据库相关的东西。在理想情况下,这部分代表业务逻辑的代码应该是整个系统的核心,其他低层概念的实现应该以插件形式接入系统中。业务逻辑应该是系统中最独立、复用性最高的代码。

架构设计的任务就是找到高层策略与底层细节之间的架构边界,同时保证这些边界遵守依赖关系规则。

4.尖叫的软件架构

架构!=框架

架构设计不应该是与框架相关的,架构应该基于用例来设计,而不应该基于框架来设计。

良好的架构设计应该可以让人第一眼看出这是个什么系统(架构应该尖叫的告诉你)。

一个良好的架构设计应该围绕着用例展开,这样的架构设计可以在脱离框架、工具以及使用环境下完整地描述用例。这就好像一个住宅建筑设计的首要目的应该是满足住宅的使用需求,而不是确保一定要用砖来构建这个房子。架构师应该花费很多精力来确保该架构的设计在满足用例的需要下,尽可能地允许用户能自由地选择建筑材料(砖头、石料或者木材)。

而且,良好的架构设计应该尽可能地允许用户推迟和延后决定采用什么框架、数据库、Web服务以及其他与环境相关的工具。框架应该是一个可选项,良好的架构设计应该允许用户在项目后期再决定是否采用Rails、Spring、Hibernate、Tomcat、MySQL这些工具。同时,良好的架构设计还应该让我们很容易改变这些决定。总之,良好的架构设计应该只关注用例,并能够将它们与其他的周边因素隔离。

5.整洁架构

软件层次从低到高分别是:

框架与驱动程序 (数据库、Web、用户界面、设备、外部接口) < 接口适配器 ( 控制器、展示器、网关) < 应用级业务逻辑(用例) <系统级业务逻辑(业务实体)

源码中的依赖关系也必须按照这个方向流动,即低层机制指向高层机制。

5.1 业务实体

业务实体这一层中封装的是整个系统的关键业务逻辑,一个业务实体既可以是一个带有方法的对象,也可以是一组数据结构和函数的集合。

5.2 用例

软件的用例层中通常包含的是特定应用场景下的业务逻辑,这里面封装并实现了整个系统的所有用例。这些用例引导了数据在业务实体之间的流入/流出,并指挥着业务实体利用其中的关键业务逻辑来实现用例的设计目标。

我们既不希望在这一层所发生的的变更影响业务实体,同时也不希望这一层受外部因素(如数据库、UI、常见框架)的影响。用例层应该与它们都保持隔离。

5.3 接口适配器

软件的接口适配器层中通常是一组数据转换器,它们负责将数据从对用例和业务实体而言最方便操作的格式,转化为外部系统(如数据库、Web)最方便操作的格式。例如,这一层应该包含整个MVC框架。展示器、视图、控制器都应该属于接口适配器层。而模型部分则应该由控制器传递给用例,再由用例传回展示器和视图。

同样的,这一层的代码也会负责将数据从对业务实体与用例而言最方便操作的格式,转化为对所采用的持久性框架最方便的格式。从该层再往内的同心圆中,其代码就不应该依赖任何数据库了。

这一层的代码还会负责将来自外部服务的数据转换成系统内用例与业务实体所需的格式。

5.4 框架与驱动程序

最外层的模型层一般是由工具、数据库、Web框架等组成的。在这一层中,我们通常只需要编写一些与内层沟通的黏合性代码。

框架与驱动程序层中包含了所有的实现细节。Web是一个实现细节,数据库也是一个实现细节。我们将这些细节放在最外层,这样就很难影响到其他层了。

6.解耦谬论

谬论:拆分服务最重要的一个好处就是让每个服务之间实现强解耦。

维服务架构中,拆分服务并不意味着这些服务可以彼此独立开发、部署和运维,如果这些服务之间以数据形式或者行为形式相耦合,那么它们的开发、部署和运维也鄙夫彼此协调来进行。如何为了满足一个需求需要多个服务共同修改,则这些服务本质上都是强耦合的,这就是横跨度变更问题。

读书·架构整洁之道(原则篇)

...静坐,一日看尽前陵碑-----猫腻《择天记》一.设计与架构究竟是什么?二.SOLID设计原则SRP:单一责任原则(SingleResponsibilityPrinciple)OCP:开闭原则(OpenClosedPrinciple)LSP:里氏替换原则(LiskovS... 查看详情

读书·架构整洁之道(原则篇)

...静坐,一日看尽前陵碑-----猫腻《择天记》一.设计与架构究竟是什么?二.SOLID设计原则SRP:单一责任原则(SingleResponsibilityPrinciple)OCP:开闭原则(OpenClosedPrinciple)LSP:里氏替换原则(LiskovS... 查看详情

架构整洁之道总结

最近对架构整洁之道进行了总结,架构要想做得好,我们得明白架构的行为价值和目标、解决的问题是什么?其次就是架构的价值和编程范式、设计原则又是什么?上图中已经给出了答案,架构的行为价值就是编写代码实现需求... 查看详情

架构整洁之道-软件架构

第十五章什么是软件架构软件架构的实质就是规划如何将系统切分成组件,并安排好组件之间的排列关系,以及组件之间互相通信的方式。设计软件架构的目的,就是为了在工作中更好地对这些组件进行研发、部署、运行以及维... 查看详情

架构整洁之道pdf下载

网盘下载地址:架构整洁之道PDF下载–易分享电子书PDF资源网 作者: 【美】RobertC.Martin(罗伯特C.马丁)出版社: 电子工业出版社出品方: 博文视点出版年: 2018-9页数: 348定价: 99.00元装帧: 平装ISBN:&n... 查看详情

架构整洁之道-架构设计二

第二十章业务逻辑通常将应用程序划分为业务逻辑和插件两部分。业务实体是计算机系统中的一种对象,这种对象中包含了一系列用于操作关键数据的业务逻辑。用例描述的是某种特定应用情景下的业务逻辑。用例更靠近系统的... 查看详情

《架构整洁之道》

...急,但是并不总是重要,在紧急重要矩阵中占据A、C位置架构价值Soft:当需求变更时,所需的软件变更必须简单方便变更实施的难度应该和变更的范畴(scope)成等比,而与变更的具体形状(shape)无关不紧急 查看详情

整洁架构之道--三种经典的编程范式(代码片段)

本文是《CleanArchitecture》--整洁架构之道中关于编程范式相关章节的笔记,首发于公众号「Go招聘」这和软件架构的三大关注重点不谋而合:功能性、组件独立性以及数据管理。的方式。回答此问题的同时另外还会搬出这三个词语... 查看详情

好书推荐探究构架设计的方法论|《架构整洁之道》

目录一、引言二、书籍简介三、架构的终极目标是用最小的人力成本来满足构建和维护该系统的需求四、总结一、引言你好,我是小雨青年,一名程序员。今天为你推荐的书籍是《架构整洁之道》。架构就是最小的人力... 查看详情

好书推荐探究构架设计的方法论|《架构整洁之道》

目录一、引言二、书籍简介三、架构的终极目标是用最小的人力成本来满足构建和维护该系统的需求四、总结一、引言你好,我是小雨青年,一名程序员。今天为你推荐的书籍是《架构整洁之道》。架构就是最小的人力... 查看详情

架构整洁之道,看这一篇就够了!(代码片段)

...历久弥新,掌握了它们,你在程序的海洋中就不会迷路,架构思想就是这样的知识。本文是《架构整洁之道》的读书心得,作者将书中内容拆解后再组织,不仅加入了个人的独到见解,而且用一张详细的知识脉络图帮助大家了解... 查看详情

《架构整洁之道》之开闭原则

...生的修改所影响,那么就应该让B组件依赖于A组件。软件架构师根据相关函数被修改的原因、修改的方式及修改的时间来对其进行分组隔离,并将这些互相隔离的函数分组整理成组件结构,使得高阶组 查看详情

架构整洁之道系列软件架构师与软件架构

...在读《CleanArchitecture》这本书,书中对与软件设计与架构的阐述是非常深刻的。因此开了一篇专栏,来记录《CleanArchitecture》书中一些优秀的架构设计理念,以及我对这些内容的思考。一、什么是软件架构师软件架构... 查看详情

markdown无瑕的程式码─整洁的软体设计与架构篇心得(代码片段)

查看详情

笔记架构整洁之道

...的前提下就可以轻易被扩展。        ⼀个好的软件架构设计师会努⼒将旧代码的修改需求量降⾄最⼩,甚⾄为0。        OCP是我们进⾏系统架构设计的主导原则,其主要⽬标是让系统易于扩展,同时限制其每... 查看详情

使用整洁架构优化你的gradlemodule(代码片段)

...id开发的同学都听说过CleanArchitecture,也就是所谓整洁架构。Google推荐我们使用整洁架构对Android业务架构进行合理分层,整洁架构的概念出自以下这本书(国内译本:代码整洁之道),关于这本书以及作者B... 查看详情

面向对象的五大基本原则(solid)

...ilityprinciple):单一职责原则OCP:开闭原则。概述出自《架构整洁之道》这本书,参考:《架构整洁之道》架构笔记,码了,回头看一下。简单来说SOLID就是面向对象编程的五大基本原则的英文缩写的首字母连起来。SRP 查看详情

my2020workschedule

Done[x]《大师和玛格丽特》[x]《漫长的婚约》[x]《架构整洁之道》[x]《查泰莱夫人的情人》DH劳伦斯OutofPlan[x]《APUE》[]《代码整洁之道》[]《代码整洁之道程序员的职业素养》Todo[]《恋爱中的女人》DH劳伦斯[]《虹》DH劳伦斯[]《文... 查看详情