架构师在团队里的角色很独特，他们不是Master却决定着何时以及如何交付软件；他们不是PO却确保软件能够满足业务目标；他们也编程但做的更多的是架构层面的Coding而不仅仅是写算法，更多的在于设计层面，包含了管理、技术和交付的职能，或者说整个产研线的工作都与这个角色有关，它不单单需要会编程，懂设计，会测试，通部署，这些只是架构师必备技能
从软件工程角度而言
软件的架构设计以人为本，软件所有利益相关方都有着对项目的预期，而架构师需要的便是与利益相关方多方协作共同定义软件项目的需求和目标，PO定义功能特性，而架构师需要挖掘功能特性后的质量属性，除此之外更要关注那些影响架构设计方向的约束和特性
分解系统分配职责
架构师只有把软件系统进行分解，才能制定出满足质量属性和其他系统性需求的策略，而这其中你要做的便是定义模块、分配模块到开发者；指定读写分离策略解决数据同步延迟，为系统的可靠性、可用性、伸缩性提供保障
关注大局
从全局角度考虑整体系统，意味着架构师需要处理的不仅仅是技术问题，人员、过程、业务需求以及其他技术和非技术因素都将影响最后的软件系统，即便是一个小小的设计决策也可能产生深远的影响，架构师必须高瞻远瞩纵观全局而不能陷入局部细节的设计
然而很多时候是个挣扎的过程，在想要达到的目标和必须接受的现实之间寻找平衡，这意味着一个优秀的架构师必须善于寻找平衡做出取舍
管理技术债务
所有的软件都有技术债务，架构师知道系统是如何分解的，知道各个模块是如何协作的，在此基础上再将业务需求和技术决策通观考虑才能管理好技术债务，技术债务是软件系统的副产品，出色的软件团队会有意的引入技术债务来实现更快的交付，后续在逐步进行偿还，从而持续的创造价值
因此识别技术债务管理技术债务便成为架构师多线程工作的其中一个线程
提升团队的架构能力
架构师是整个团队的导师和顾问，设计炫酷却无人理解的架构毫无意义，作为团队的架构专家，向团队分享知识，帮助团队提升架构思维同样是架构师多线程工作中的其中一个线程，因此组队设计、文档授业解惑，代码Review便成为架构师完成此项职能的“方法”
软件架构
软件架构是从零开始组织软件的一系列重大设计决策的集合，集合的目的便是实现期望的质量属性和其他软件特性，设计得当的架构能够提升利益相关方需要的质量属性，抑制或消除利益相关方不需要的质量属性，同时还可以提升其他属性，例如好的架构势必能够提升开发效率，多快好省
定义基本结构
软件应该有主体结构，这个结构定义的是软件系统的组织和协作方式，它体现在你编写的代码和运行的软件中，甚至体现在开发者之间的写作中；将两个元素以某种关系链接在一起就形成了结构，而元素是软件的基本组成部分，关系则描述了元素如何协作完成任务
基本结构的设计切忌空想
通常情况下可以使用三种类型的元素和关系来构建架构，这三种类型分别为模块、组件连接器和分配
| 类型 | 元素 | 关系 |
|---|---|---|
| Module | 类、包、层、存储过程、模块、配置文件、数据库表等 | 使用、允许使用、依赖等 |
| Component&Connector | 对象、连接、线程、进程、层、过滤器等 | 调用、订阅、管道、发布、返回等 |
| Allocation | 服务器、传感器、台式机、负载均衡器、团队、用户、Docker容器等 | 运行于、负责、开发、存储、支付等 |
- Module： 存在于设计阶段，编写代码的过程也是与模块进行交互的过程，软件没有运行，模块结构仍然存在于文件系统中
- 组件连接器： 在软件运行时出现，组件可以创建与其他组件的链接、产生新进程以及实例化新对象，与Module不同的是它在系统不运行是便不复存在，只能从其运行留下的日志或数据库条目中看到其身影
- Allocation：展示了模块与组件连接器之间以及这些元素与现实的物理元素之间的协同与响应关系，它也被称为映射，因为它显示了元素之间的相互映射关系，例如某个元素运行在客户端还是服务器、A团队负责构建系统的哪个部分等等
- 不同类型的结构适合用来思考不同的系统特性，例如Module考虑可测性和可维护性、组件连接器则考虑运行时问题可用性和性能，而如果发现使用了混合结构，例如静态元素使用了动态关系，则说明设计欠考虑
- 结构决定了系统的身形轮廓，身形轮廓决定了用户体验到的质量属性和其他特性
实例参考
- 元素：命名要明确具体，不要忘记他们之间的关系
- 考虑模块结构：使用了哪些方法或类？这些类是否存在于不同的包或者命名空间？包管理器和构建脚本中包含哪些依赖关系？
- 考虑C&C结构：软件在运行时是否与其他进程或者系统发生交互？谁在调用系统，它是如何响应的？
- 考虑分配结构：软件各个部分有谁负责开发？如何部署？
推演质量属性
- 软件系统并非单纯的功能实现，还要做到速度快、可靠、可扩展、可维护，质量属性是利益相关方判断软件系统是否好用的一切外部可见特性，包括可伸缩性、可用性、可维护性、可测试性等等，与软件交互用户就能体验到这些质量属性
- 选择架构的结构实际上就是选择你想在软件系统中提升的质量属性，思考架构设计可以确保你设计的软件系统能够支持你关心的质量属性
- 是质量属性让你独一无二，即便两个软件架构完全一样，实现的功能需求也一样，不同的是质量属性
出色的软件
架构使软件成功的基础
- 架构将大问题分解为容易处理的小问题：现代系统庞大且复杂，架构精确地解释了如何将系统划分为轻巧、独立的小模块，同时确保整个系统协同工作，让系统的价值高于各个部分的价值之和
- 软件架构告诉我们如何协同工作：软件开发既是技术也是人际沟通的艺术，软件架构描述了整个（包括开发者）如何组成有机的整体，掌握了架构也就清楚了人们该如何合作开发软件，系统越复杂这一点越重要
- 软件架构为讨论负责设计提供了基本词汇：不明白彼此在说什么就无法合作，软件架构提供了沟通必备的基本概念和词汇，这样可以把时间用在解决用户问题上
- 软件架构关注的不仅仅是功能：软件的特性和功能很重要，但他们不是决定软件是否出色充分条件，架构除了考虑功能需求外，还要考虑成本、约束、进度、风险、团队交付能力，以及最重要的唯一的质量属性
- 软件架构让你避免犯重大错误：软件架构是重要的设计决策，其重要程度可以用变更的成本来衡量
- 架构让软件更灵活：如果没有架构，软件就像水一样无法控制，架构为软件提供了灵活应变的结构