
软件架构
文章平均质量分 68
翻译自《Software Architecture in Practice》第三版,原作者Len Bass、Paul Clements、Rick Kazman,单纯学习使用,如有违权请联系删除。
Korbin Luo
这个作者很懒,什么都没留下…
展开
-
架构整洁之道-软件架构-测试边界、整洁的嵌入式架构、实现细节
测试代码是系统组件,遵循依赖原则独立部署。通过专用API解耦,防止脆弱性并支持架构演进。嵌入式架构采用分层抽象(HAL、PAL、OSAL),确保硬件变更不影响软件,实现可测试性和长期适应性。原创 2024-02-05 15:29:14 · 1279 阅读 · 0 评论 -
架构整洁之道-软件架构-展示器和谦卑对象、不完全边界、层次与边界、Main组件、服务
展示器、谦卑对象模式在软件架构边界设计中起到重要作用,通过划分系统行为提升可测试性。服务内部组件边界才是架构关键,而非服务本身。遵循依赖关系规则解决横跨型变更问题。原创 2024-02-05 15:25:00 · 1272 阅读 · 0 评论 -
架构整洁之道-软件架构-策略与层次、业务逻辑、尖叫的软件架构、整洁架构
软件架构设计据变更划分策略,低层依赖高层组件解耦。强调独立于框架、围绕用例构建,保持核心逻辑纯净且易测试替换技术实现。同心圆模型隔离机制与策略,遵循内部不受外部影响的依赖原则。原创 2024-02-01 18:09:06 · 1343 阅读 · 0 评论 -
架构整洁之道-软件架构-概述、独立性、划分边界与边界剖析
架构设计关键在组件划分、交互方式,旨在提高开发维护效率及程序员生产力,降低成本,应独立于设备,支持用例执行和模块解耦以适应变化,涉及单体结构至服务的多层级边界划分。原创 2024-01-30 18:59:07 · 1656 阅读 · 0 评论 -
架构整洁之道-组件构建原则
组件构建原则指导软件架构设计,包括组件聚合的REP、CCP和CRP原则以及耦合相关的无依赖环、稳定依赖与稳定抽象原则,旨在优化依赖结构、降低耦合度并适应项目演进。原创 2024-01-29 17:03:10 · 1396 阅读 · 0 评论 -
架构整洁之道-设计原则
SOLID包括:单一职责(每个类专注于单一功能)、开闭原则(扩展不修改原有代码)、里氏替换(子类能正确替代父类)、接口隔离(避免大而全的接口)及依赖倒置(高层模块依赖抽象而非具体实现)。原创 2024-01-26 15:35:56 · 1471 阅读 · 0 评论 -
架构整洁之道-价值维度与编程范式
设计与架构本质上相同,强调一体化和灵活性以低成本满足系统构建维护需求。软件价值体现于行为与架构两维度。编程范式包括结构化、面向对象和函数式,各对程序控制转移或赋值进行规范约束。原创 2024-01-26 11:21:17 · 1340 阅读 · 0 评论 -
2.4 增强干系人之间的沟通
软件架构代表系统的通用抽象,系统的大多数(如果不是所有的话)干系人可以用它来作为建立相互理解、协商、形成共识及互相之间沟通的基础。架构,或架构的部分,能够充分地抽象,以便很多非技术人员能够充分地理解它,特别是在架构师的指导下,而且这些抽象可以被提取为充分丰富的技术规范,用于指导实现、集成、测试和部署。 每个软件系统的顾客、用户、项目管理者、开发人员、测试人员等等这些干系人——会受到受架构影响的系统的不同特征影响。例如: (1) 用户关心系统是快的、可靠的,并...翻译 2021-11-16 20:58:47 · 335 阅读 · 1 评论 -
2.3 预测系统质量
如上文所述,架构不只使系统具有质量,也能够预测系统质量。在系统被开发和部署之前,不能说已经有适当的架构决策(也即,系统是否展示它所需的质量属性),因而选择一个架构是不可能完成的任务,随机地进行架构选择跟任何其他方法一样有效。幸运的是,仅基于对系统架构的评估就可以对系统进行质量预测。如果我们知道特定的各种架构决策可以决定系统的特定的质量属性,那么我们可以做出这些决策,并适当地期望得到相关质量属性的回报。事实上,当我们对架构进行检测时,我们可以看看这些决策是否已被做出,并自信地预测到架构将展示的...翻译 2021-09-28 15:30:25 · 220 阅读 · 0 评论 -
2.2 对变更进行推理和管理
可变性——系统进行变更的容易程度——是一个质量指标(因此前文用变量来表示),因为它极其重要,所以我们把它放在了前文的十三个重要项里面。软件开发社区发现,典型的软件系统中,80%的成本发生在第一次部署之后。也即,在大多数系统中,人们的大多数工作都是在这个阶段。很多程序员及软件设计师的工作内容被限制在现存架构和已有代码的维护过程中。事实上所有软件在生命期内都会发生变更,可能是添加新功能,可能是为了适配新的运行环境,可能是修改Bug等等。但这些变化往往充满困难。 每个架构部分都可能...翻译 2021-09-24 13:49:50 · 118 阅读 · 0 评论 -
2.1 禁止或启用一个系统的质量指标
系统是否允许展示其渴望的(或需求的)质量指标在很大程度上取决于其架构。 本书的第二部分会对此进行更加详细地阐述。在此之前,请记住以下示例: (1) 如果你的系统需要高性能,那么你需要注意管理元素基于时间的行为,它们共享资源的使用,以及元素间通信的频率及容量。 (2) 如果可变性很重要,则需要注意分解每个模块的职责,以保证系统的大部分变更都只会影响少部分模块(最理想的状态时,每个变更只会影响一个元素)。 (3) 如果你的系统要求高...翻译 2021-09-17 15:31:41 · 129 阅读 · 0 评论 -
2 为什么软件架构很重要
Software architecture is the set of design decisions which, if made incorrectly, may cause your project to be cancelled.-Eoin Woods 为什么需要架构? 本章将聚从技术视角来阐述架构的重要性。我们将从以下几方面展开: 1 架构可以控制系统对质量指标的掌控。 2 在架构中的决策可以用来推断或管理系统演化过程中的...翻译 2021-09-16 22:09:44 · 1770 阅读 · 0 评论 -
1.4 好的架构由什么组成
实际上并不存在一定好或者不好的架构。每个架构都或多或少地适用于某些场景。三层面向服务架构可能只是一个大型的基于B2B企业系统的入门架构,但对于航空应用来说则足够了。为实现高可修改性而精心设计的架构对于一次性原型并没有意义(反之变然)。本书的一则消息是,架构事实上是可以被评估的——重视架构的最大收益之一——但只在特定状态目标的背景下。 然而,当设计大部分架构时,还需要遵守一些经验法则。如果不应用任何一项经验法则,并不意味着架构有致命缺陷,但至少应该作为一个警告信息,应该进行调...翻译 2021-09-16 17:38:46 · 174 阅读 · 0 评论 -
1.3 架构模式
在某些场景下,架构元素是由解决特定问题的方式组件成的。随着时间的推移,人们发现这种组合的方式在许多不同领域都很有用,因此这种方式被广泛记载和传播。架构元素的这种组合方式,叫做架构模式,提供了解决一些系统问题的一整套策略。 架构模式描绘了用于解决问题的元素类型及其交互形式。模式可以根据它们使用的架构元素类型进行特征化。例如,常见的模式类型模式如下:层模式:当软件元素间的使用关系是严格单向时,就会出现一个层系统。层是一组连贯的相关功能。在严格的分层结构中,层只能使用其正下方...翻译 2021-09-15 11:55:00 · 151 阅读 · 0 评论 -
1.2 架构结构和视图
神经科医生、骨科医生、血液科医生和皮肤科医生对人体结构都有不同的看法。眼科医生、心脏病专家和足病学家专注于特定的子系统。运动学家和精神病医生关注整个安排行为的不同方面。尽管这些视图的描述方式不同,属性也非常不同,但它们都有内在的联系:它们共同描述了人体的结构。图1所示。显示人体的几种不同的视图:骨骼、血管和x光。 软件也是这样。现代系统往往过于复杂,无法一次掌握全部。相反,我们将注意力限制在软件系统的一个(或一小部分)结构上。为了对架构进行有意义的交流,我们必须弄清楚我...翻译 2021-09-15 10:03:18 · 1080 阅读 · 0 评论 -
1.1 软件架构含义
The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.翻译 2021-08-16 19:33:01 · 680 阅读 · 0 评论 -
1 什么是软件架构
Good judgment is usually the result of experience.And experience is frequently the result of bad judgment. But to learn from the experience of others requires those who have the experience to share the knowledge with those who follow.-Barry LePatner翻译 2021-09-15 14:27:42 · 165 阅读 · 0 评论