源页面:
导入说明:
- 原页面中的临时签名图片未本地落地。
- 原页面中的 alias、bookmark 块未展开。
- 页面末尾存在 Notion 数据库引用,已跳过。
一、架构师职责
- 顶层视角,多维度思考,跨团队跨行业思考
- 要仰望星空,做技术规划和产品规划
- 架构师既要有做规划的能力也要有能推动其他团队或带领团队落地的能力
- 要在保持代码敏感性的同时减少自己码代码的时间占比,从单打独斗到带领团队落地
- 技术广度深度都比高级/资深前端更高一层,技术视野很开阔,会画架构图,对于前端架构领域有独到的见解
二、架构方法论
1. 为什么需要架构
假如没有架构设计
- 应用服务的边界不是很清晰
- 应用服务层次不清晰,系统耦合严重
- 系统应用服务跟踪问题
- 系统服务监控问题
- 技术体系失控问题
什么时候需要架构设计
- 需求相对复杂
- 非功能性需求在整个系统占据重要位置
- 系统生命周期长,有扩展性需求
- 系统基于组件或者集成的需要
- 业务流程再造的需要
2. 架构是什么
总结一下架构的组成 = 要素 + 结构 + 连接,将系统要素按照特定结构进行连接交互。
我在这里重新定义架构:软件架构指软件系统顶层结构设计。架构是经过系统性思考、权衡利弊之后,在现有资源约束下做出的相对合理决策,最终明确系统骨架,包括子系统、模块、组件,以及它们之间的协作关系、约束规范和指导原则,并由此指导系统设计和团队协作。
架构设计的作用
- 决策:系统性思考后的合理决策,例如技术选型、实施方案、成本评估、性价比评估等
- 结构:明确的系统骨架,明确系统由哪些构件组成
- 连接:系统协作关系,明确各组成部分如何协作来实现业务请求
- 规范:约束规范和指导原则,保证系统有序、高效、稳定运行
3. 架构分类
RUP 4+1 架构视图
- 原页面包含配图,未本地落地
- RUP4+1 架构方法主要是以架构生命周期为视角进行描述
- 逻辑视图:描述系统软件功能拆解后的组件关系、组件约束和边界,反映系统整体组成与系统如何构建
- 开发视图:描述系统的模块划分和组成,以及内部包的组成设计,服务于开发人员
- 物理视图:描述软件如何映射到硬件,反映系统在分布方面的设计以及部署方式
- 处理流程视图:描述系统软件组件之间的通信时序、数据输入输出,通常由时序图和流程图表示
TOGAF9
- 原页面包含配图,未本地落地
- 按架构涉及内容维度进行描述
三、相关资料
- 原页面包含若干 alias / bookmark 块,未展开
- 已跳过数据库引用
Discussion
留言与讨论
想法、补充和不同意见都欢迎。