架构师修炼之道学习笔记

软件架构师的角色

架构师的职责

 

软件架构的组成

 模块结构存在于设计阶段，组件连接器结构在软件运行时出现，分配结构展示模块元素与组件连接器元素之间，以及这些元素与现实的物理元素之间的协同与响应关系

软件架构的意义

是开发出色软件的基础。架构从以下六个方面有指导意义

架构设计思维

设计策略

首先挖掘关键架构需求

 主动选择架构

架构模式

模式	元素	关系	优点	缺点
分层模式	层：一组功能内聚的模块	哪些层可以使用其他层的模块	可运维性，可移植性，可复用性，可测试性，设计阶段的可修改性，概念上比较容易实施	每一层都引了额外的抽象，增加了复杂度，可能会影响性能，层数繁多和抽象泄露可能导致开发过程非常痛苦
端口适配器模式	层：包含业务逻辑，便它不清楚使用的数据和事件的来源 端口：层与适配器之间的接口。借助端口，层可以与具体的适配器分离 适配器：与外部数据源，设备或其他组件进行交互的代码，使得层能够访问数据和事件。	暴露：指明层可用的端口 实现：指明约束适配器的端口 注入：指明层可用的适配器	提升可测试性，可维护性，可修改性。团队可以分工完成不同的层和适配器	必须建立机制选择运行时使用的适配器。适配器决定了运行时质量。
管道过滤器模式	过滤器：读取，转换，记录数据的组件。过滤器必须定义预期输入并输出结果 管道：连接器，用于将数据从一个过滤器传输到下一个过滤器。管道具有单一输入和输出，不会改变传输的数据 一些变种还包含元素源（source)和槽(sink)。前者产生数据，后者仅接收数据	接驳：通过管道，连接一个过滤器的输出与另一个过滤器的输入	提升性能，可复用性，可修改性	管道过滤器系统不是交互式的。不会明显提升可靠性，可能会影响性能。
面向服务架构模式	服务：可独立部署的单元。通过定义好的接口提供服务功能 服务注册表：列出所有可用的服务，以便服务可查找其他可用服务 消息系统：取决于具体的系统设计	根据SOA系统的约束而变化。可能是调用，可能是发布，订阅	提升互用性，可复用笥，可伸缩性。	带有分布式计算的所有复杂性。集成复杂。
发布订阅模式	发布者：发布事件的组件 订阅者：订阅事件的组件  事件总线：负责登记组件订阅和传递发布的事件。	发布：组件装饰事件发布到事件总线 订阅：组合登记订阅事件	提升可扩展性，可复用性，可测试性，可用性，可靠性，可伸缩性	性能很难判断
共享数据模式	数据库：保存访问器共享的数据 数据访问器组件：以某种方式使用数据的组件	读取：数据访问器组件可以从共享数据库中读取数据。 写入：数据访问器组件将数据写入共享数据库	通过数据一致性、安全和隐私提升可靠性。如果数据库充分优化，数据访问器划分良好，也可以提升可伸缩性和可用性	单点故障，影响可用性和性能。如果数据库发生变更，可维护性也会受影响。
多层模式	层(tier)：运行时组件的逻辑组。	属于：将组件归到某一层 通信：层或其内部组件与其他层的交互 允许通信：表明哪些层可以与其他层中的组件通信 分配到：将层映射到物理计算平台	提升安全性，性能，可用性，可维护性，可修改性，有利于分析成本和部署	作为运行时构造，在大型系统中实施可能会有难度，太多的层可能会抑制系统性能和可维护性。
能力中心模式	CoC团队：开发人员和架构师小组  责任区域：架构的子集，可以是模式，技术，用例	负责：聚首CoC团队及其责任区域	提升专家的可复用性和可伸缩性，从而提升多方面的质量属性。	CoC让一些专家形成了知识上的孤岛，且容易因人员流失而出现知识流失，能力不足的CoC成员会引发问题，影响开发质量。
开源贡献模式	团队：提交或审核组件变更的小组 库：包含软件组件的版本普瑞玛存储率	拥有：团队负责审查变更并维护库的完整性。 可能贡献：表示可能向库提交变更的团队	提升可复用笥，可维护性，开发速度	与组件划分策略密切相关。在多数情况下，贡献的学习曲线极其陡峭，这种模式不太现实 。
大泥球模式	无	无	短期内提高开发速度	降低系统的可维护性，可扩展性，缺少设计的完整性，毫无章法的开发和缺乏架构知识

 分层模式与多层模式的区别：

• 分层模式是模块结构，处理设计时元素，多层模式是组件连接器结构或者分配结构，处理运行时元素

建立模型

 架构设计研讨会

架构设计研讨会流程

阶段内容

1、准备：提前了解要探索的问题

2、启动：向团队介绍研讨会的目标和问题背景

3、创建：制作模型，绘制草图，构建原型

4、分享：展示创建的内容，并具体描述设计如何实现目标

5、评判：团队对分享的内容进行评判，就设计能否完成目标发表意见

6、迭代：重复第3到5步，优化模型，创建新模型。

7、跟进：针对发现的想法，风险，问题决定后续处理步骤

展示设计决策

描述架构

 

4+1视图

 逻辑视图：描述软件的功能逻辑，由哪些模块组成，模块中包含哪些类，其依赖关系如何。逻辑视图主要支持功能需求，也就是系统应该提供怎样的服务给用户。系统分解为一组关键抽象，如问题域的对象或对象类的形式。利用封装和继承的抽象原则。分解不仅是为了功能分析，也为了识别常见的服务机制和跨系统的设计元素。我们可以使用UML类图和类模板代表逻辑视图的方法

开发视图：包括系统架构层面的层次划分，包的管理，依赖的系统与第三方的程序包。开发视图某些方面和逻辑视图有一定重复性，不同视角看到的可能是同一个东西，开发视图中一个程序包，可能正好对应逻辑视图中的一个功能模块。开发视图关注实际的软件开发环境中的软件模块组织。软件打包可以小程序库或子系统等形式，子系统是由一个或少量的开发人员开发的系统。子系统有良好的组织层次结构，每一层都提供了一个狭窄的和良好定义的接口层。开发系统是由模块和子系统的架构组成的，表达了"出口"和"进口"的关系

处理视图：描述程序运行期的进程、线程、对象实例，以及与此相关的并发、同步、通信等问题。处理架构是考虑一些非功能性的需求，例如性能和可用性可扩展性Scalable。它可以解决并发性和分布系统的完整性与容错性等问题，主要指导如何从逻辑视图的抽象融入处理架构之中，比如哪个线程来控制对象的实际执行。

物理视图：描述软件如何安装并部署到物理的服务上，以及不同的服务器之间如何关联、通信。主要考虑系统的非功能性需求，如可用性、可靠性(容错)、性能(吞吐量)和可伸缩性。

场景视图：针对具体的用例场景，将上述 4 个视图关联起来，一方面从业务角度描述，功能流程如何完成，一方面从软件角度描述，相关组成部分如何互相依赖、调用。四个视图中的元素通过场景能够一起无缝工作，场景对应着用例，它实现上对应相应的脚本(流程)，也就是对象之间的序列交互，使用对象场景图和对象交互图来表示

C4视图

类Classes：软件系统的最小构建块

组件Component：由一个或者多个类组成的逻辑组，由许多相互协作的类组成，位于高层协议下面。

容器Containers：表示组件运行或者驻留的地方。

系统System：是高层抽象

架构评估

 

架构设计实践模型

​

参考资料：

https://www.jdon.com/artichect/4+1view-architecture.html

https://blog.csdn.net/weixin_42248522/article/details/123381118