前言
大家好，我是小郭，最近在看程序员向架构师转型这本书，同时也做了思维导图的笔记，确实也是有一些收获，在为做好一个架构师而做准备，通过学习架构设计的原则到设计架构的过程来对架构师的工作有更大而全的认识。
书籍
软件架构设计-程序员向架构师转型
👍 架构设计的原则
在实际的工作中，作为程序员，我们做的工作是
获取需求 -》 需求分析 -》 需求评审 -》技术评审 -》代码落地。
那架构师的工作是什么呢？有一句话是“需求决定架构”，我认为架构师应该是从更高的角度来看整体的需求，找到需求之间的矛盾关系，以及 预见系统问题的思考，从而做到对需求的划分和技术设计。
【三大原则】
- 看透需求
怎么看透需求呢？通过将需求找全，梳理需求项之间的矛盾关系，追溯关系并且搞清除关系。 - 架构大方向正确
我们常说方向不对，努力白费，就好比我们出去和女孩子约会，都需要先问对方爱吃什么，有什么忌口吗，在考虑是自己做还是下馆子，通过投其所好来实现最终的目的。
所以 关键需求 决定 概念架构。 - 设计好架构的各个方面方面一：细化架构
- 根据需求级别来划分子系统
- 确认采用的架构风格和开发技术
- 方面二：验证架构
通过运行期质量评估和开发期质量评估进行验证架构，从而进行架构决策
👍 架构设计的过程
1. 需求分析
通过愿景分析搞清楚要做什么
愿景分析 = 业务目标 + 范围 + Feature + 上下文图
Feature：不同粒度的功能内容和特色 上下文图 - 顶层数据流图 - 黑盒的用例图 用例图:描述软件系统为用户或外部系统提供的服务 参与者Actor 用例Use Case 用例简述:谁在什么时间干了什么
在需求分析的环节，不是一上来就是一顿套用，我们可以先确认需求的大小，来决定分析的步骤。
三套理论
架构设计只有合适，没有最好。
无视条件差异进行照抄都是一件很危险的事情
| 需求大小 | 步骤 |
| 小 | 1. 确定业务目标 2. 编写用例 |
| 中 | 在小的基础上，新增范围+Feature+上下文图 |
| 大 | 在中的基础上，新增业务流程建模，通过角色角度来分析， 1. 谁使用系统， 2. 谁来维护， 3. 系统需要和外部哪些系统进行交互 |
速查手册
2. 领域建模
目的：利用需求分析提供问题领域的语境，透过问题领域，建立稳固的领域概念。
在领域建模的时候，更重要的是注重于用户/客户的沟通，避免用户参与不足，造成了需求分析中假设的成分过高。
利用好状态图，跟踪流转的情况
三大原则中，第一个原则就是看透需求，在实践的过程中，主要是利用需求分析和领域建模来完成。
下面就是我们确定大方向的时候了
3. 确定关键需求
架构师的难点在预见系统问题的思考方式，以及对问题的权衡。
- 权衡需求点，都需要我们去权衡和考量的
- 功能需求，指的就是客户想要看到的东西，如果只考虑功能需求会导致过度理想。
- 非功能需求，指的是质量属性，以及一系列的业务环境、使用环境、构建环境、技术环境给我们带来的约束。
- 关键需求决定架构，其余需求验证架构
关键需求决定架构 这句话什么意思呢？总结下来就是以结果和数据说话，结合重要的功能、约束做出架构设计，注重所有功能的理想化，避免延期或者是方向错误造成的需求大改。
其余需求验证架构，从每项非关键需求的角度对架构方案进行走查。
如何确定关键需求？
- 确定关键质量，确定着重提高哪些方面的质量属性要求，充分考虑质量属性的相互制约或相互促进关系，来调整不同质量属性的要求标准。
- 确定关键功能 确定关键质量，质量属性之间往往具有相互制约性
主要确定的关键功能有核心功能、必做功能、高风险功能、特殊功能
核心功能和必做功能都是一个系统的核心，必须对这些功能的设计更加充分，理清模块关系的同时增加对这些功能的扩展性和预见问题的思考。
4. 概念架构设计
概念架构设计指的是目标的设计思想和重大选择。
概念架构界定系统的高层组件，以及它们之间的关系，但是不涉及具体的实现细节。
1. 利用鲁棒图完成功能需求到设计的鸿沟
先完成角色与职责间的关系，然后开始增量建模，发散出来控制对象和边界对象。
利用目标-场景-决策表，来引入新的设计，进而改进老的设计，这就是架构师要考虑的因素，包括了价值、代价、开发难度、技术选型、出现次数等。
2. 设计任务
架构概念设计主要是功能和质量 以及设计任务，架构设计需要明确的是
- 决定：如何划分顶级子系统
- 选择：架构风格选型
- 选择：开发技术选型
- 选择：集成技术选型
3. 架构备选
不考虑备选架构是危险的，未来因为某些原因造成架构大改的时候就要付出更多的时间和经历。
通过上面的确定关键需求和概念架构设计，就已经确定了大方向，最后就是我们的设计好架构的各个方面环节
5. 细化架构设计
架构的重点，把难以处理的大问题分解成便于管理的小问题。
架构的难点就是系统之间各个部分的联系，如要深入理解系统，就需要学好系统思考，并对他一个整体进行审视。
从四个维度去做细化架构的工作
- 逻辑架构：模块划分、接口定义、领域模型
- 开发架构：技术选型、文件划分、编译关系
- 物理架构：硬件部署、软件部署、方案优化
- 数据架构：技术选型、存储方式、数据分布
6. 架构验证
不值得验证的架构，就不值得设计。
验证的方式
- 原型法 这里主要说下垂直演进原型，他和我现在说的多次交付，增量交付其实是差不多的
但是为了验证架构，将选定的功能特性完整的实现，目的是让架构更快的跑起来，营造出我们想要的场景，进而更快的发现问题，对我们越有利。 - 框架法
- 测试运行期质量
通过测试，发现架构的性能或者扩展性不能达到要求，尽快调整 - 评审开发期质量
架构原型开发人员进行评估，基于此架构开发的可测试性和重用性
验证架构步骤
验证架构步骤
- 实现架构原型
- 进行运行期质量测试得到运行期质量属性评价
- 进行开发期质量评审得到评估结果
- 基于2和3的结果，进行架构决策
总结
可以看到每一个步骤直接都是相辅相成的，必须依靠环环相扣，才能让我们的架构更加的稳固，在实际的架构设计中我们既需要思考他的纵向也需要思考他的横向。
