1. 概述
1.1. 架构设计
软件系统规模越来越大，将会面临的问题也在增加，可靠性、安全性、可伸缩性、可移植性、可用性等。在开发前，从宏观上对复杂的软件系统进行中长期的规划是必要的，同时开发过程中，也需要持续地关注各部分细节、预测规避风险
软件系统的祖传与特性：
- 软件系统可以提供的功能，即逻辑架构
- 软件系统的代码层次结构，即开发架构
- 软件系统的部署与网络结构，即物理架构
- 软件系统数据结构，即数据架构
- 软件系统的性能特征，即运行架构
1. 边缘界定
对架构系统的边界进行界定，在预测扩展性的同时避免全能系统，消耗大量资源
2. 风险识别
识别到开发过程中，现在、未来遇到的风险来源、风险产生节点、风险产生条件，是一件从始至终的任务
3. 模块切分
对不同功能的代码模块分开，类似于微服架构，使得各个模块之间耦合度降低，提高效率，减少互相的影响
4. 建立联系
在模块拆分后，需要建立起各个模块的联系沟通，使软件最终依然为一体，并且各个小组之间也需要建立起协作的工作方式
5. 细化问题
大问题切割成小问题，能够根据问题细化工作切分、沟通的粒度
1.2. 架构师
架构师是一个需要带领团队协作，承接产品和开发，统筹各小组的岗位。需要在技术和业务方面都有较高的理解与经验。在掌控全局的同时，也需要洞悉局部。作为软件的设计者，在初期有一个好的架构设计，对开发过程至关重要，减少不必要的重复成本，保持开发效率。
1. 确认需求
在和产品、需求方、用户反复沟通，不断调整后，确认需求，保证其准确性
2. 系统规划
拆分整体系统，形成不同的层级和功能模块（横向纵向），并建立起之间的联系。在开发过程中，制定每一个阶段的任务，控制迭代方向，处理需求优先级
3. 技术选型
了解很多技术栈，有充足的经验，提出针对当前软件系统的一套合适的技术选型，并且和产品、开发团队进行权衡，确认方案
4. 规格说明
作为项目的技术权威和指导，制定一套项目的规格说明，能够为各个小组了解其他人员的分工、工作内容，及小组间的责任与联系，并且为开发提供技术参考
1.3. 如何成为优秀的架构师
优秀的架构师需要的能力：
- 系统分析能力：抽象思维和分析能力，抽象出事务的共性，将业务转换为技术实现
- 架构设计能力：设计系统时能够在实现功能的基础上，降低其他风险并解决问题
- 研究攻关能力：有高超的技术算法能力，和开发能够精确的沟通，提供指导
- 技术管理能力：持续关注前沿技术，能够权衡不同技术栈的利弊，找到合适的选型
- 带人识人能力：在招聘和知识传递上有见解，能够找到适合的人选，更好的传递
所以成为一个架构师，需要有以下方面的工作：
- 加深业务理解
- 重视理论基础
- 系统性的学习
- 站在技术前沿
优秀的架构师需要做到的：
1. 对业务及其痛点有深刻的理解与思考。理解业务、充分挖掘用户痛点，同时满足显性隐性需求，做出完善专业的产品
2. 能够将技术落地产生业务价值。制定短期计划尽快满足用户需求并上线，同时也制定长期计划控制迭代方向
2. 五视图法架构设计
软件架构不是一次性劳动，不是一蹴而就的，是一个长期的重复工作
架构设计包括：需求澄清、功能梳理、领域建模、系统选型、模块划分等
迭代过程中，依据开发情况和部门沟通情况，对架构设计进行持续调整
1. 逻辑架构
随着迭代架构师需要和需求方一起，制定一套产品需求说明，给出一个结构化表达的用例模型——逻辑架构
2. 领域模型
以用例模型（逻辑架构）为出发点，架构师与需求方、业务人员沟通，构建领域模型，作为业务系统和软件系统的连接点
3. 数据架构、开发架构、运行架构
建立领域模型之后，架构设计活动逐渐过渡到纯粹的软件工程层面，架构师与开发人员讨论得出：
- 数据架构：确定合适的数据架构
- 开发架构：确定软件模块划分、接口定义、代码组织方式、集成方式等开发架构
- 运行架构：确定响应时间等性能指标，可靠性、安全性等质量指标，这些也称为运行架构
4. 上线部署
五视图完成之后，上线部署、完成产品的发布，并提供给用户使用
|
==接口的定义与实现==
普通类：只有具体实现
抽象类：具体实现和规范（抽象方法）都有
接口：只有规范
接口就是规范，定义的是一组规则，体现了现实世界中”如果你是……则必须能……“的思想，例如：如果你是天使，必须有一双翅膀。
接口的本质是契约，就像我们的法律一样，制定好后大家都遵守。
OO的精髓，是对对象的抽象，最能体现这一点的就是接口。为什么我们讨论设计模式都只针对具备了抽象能力的语言（比如c++、Java、c#等），就是因为设计模式所研究的，实际上就是如何合理的去抽象。
声明类的关键字是class，声明接口的关键字是interface。
|
2.1. 逻辑架构设计
逻辑架构应该以用户使用与功能为出发点，主要关注行为或职责的划分
静态方面为抽象职责划分、动态方面是不同职责之间的交互与协作
逻辑架构着重考虑软件功能性需求：
- 系统功能树：系统功能划分为几个子系统与功能模块？
- 用例模型：向什么样的用户提供什么样的功能？
- 用例描述：每个功能都是怎么样的操作流程与分支？
- 界面原型：如何通过界面与用户交互
- 领域模型：应当设计哪些业务实体？以及相互的关系？
- 接口描述：与哪些外部系统接口？是怎么样接口？
逻辑架构设计过程分为下面三个步骤：
- 用例模型分析
- 界面原型设计
- 领域分析、
2.2. 数据架构设计
数据架构设计重点在于对数据结构的分析、处理，使用原文分析法、四色建模法、事件风暴法等方式建立领域模型设计和数据库设计文档
领域模型描述了领域中的数据与实体的关系图：实体、实体的方法、联系，为数据库提供指导
|
==三种领域模型设计方法==
1. 原文分析法
提取出原文（初始用例）中的名词、动词，逐个权衡考量是否适合成为实体，是否适合成为实体属性，实体的行为，其余的排除掉，最终绘制出领域模型
2. 四色建模法
1. 首先建立时标性对象，作为建模的起点，也是整个领域模型的骨干
2. 之后补充实体对象（人、地点、物），丰富模型，更好地描述业务概念
3. 在此基础上，增加角色到流程中，做进一步抽象
4. 最后再把一些需要描述的信息，放入描述对象
四色建模法的次序与重点：
1. 首先以满足管理和运营的需要为前提，寻找需要追溯的事件
2. 根据这些需要追溯，寻找足迹以及相应的时标性对象
3. 寻找时标对象周围的人、事、物
4. 从中抽象角色
5. 把一些信息用描述对象补足
3. 事件风暴法
一种快速探索复杂业务领域和对领域建模的实践。集合组织者、领域专家、项目成员，使用头脑风暴的形式，从领域中关注的业务事件出发，在此过程中团队经过充分讨论，统一语言，最后找到领域模型
|
2.3. 开发架构设计
开发架构主要关注的是系统规划，分层架构，技术选型，开发规范和接口定义
1. 系统规划
系统规划既要做好当前版本，也要对未来做好方向性设计，奠定产品建设的节奏和趋势
系统规划不一定非常细节，不一定绝对正确，但基于当前是一个支点，也是对未来发展的预判，需要在后续工作中不断修正
2. 分层架构
简而言之，基于“分而治之”思想，按照一定逻辑，把复杂的系统切分为多个子系统（板块）
3. 技术选型
技术选型是对产品非功能需求、架构设计中的各种要素及约束的综合评估以及体现。技术选型是各个方面各种因素的综合抉择的结果，需要对产品、架构的把握以及对各项技术框架的熟悉程度
4. 开发规范
开发规范用于知道整个团队在开发中要遵循的事项，为团队提供统一的参考，从而提高效率和质量，避免重复工作和不必要的沟通成本
开发架构的设计着重考虑开发期质量属性：
- 可扩展型
- 可重用性
- 可移植性
- 易理解性
- 易测试性
2.4. 运行架构设计
运行架构重点考虑的是软件系统运行期间的非功能性需求，核心是运行的质量
关注系统的并发、同步、通信等，常见问题比如线程同步、死锁问题、生命周期管理
运行架构的设计关注的点在于局部的关键点和难点，常常需要技术攻关和预研
1. 运行
- 同步 vs 异步
- 并发 vs 串行
2. 交互
- 对象间的交互
- 状态转换
3. 质量
- 安全性
- 可靠性
- 可伸缩性
4. 性能
- 响应时间
- 吞吐量
2.5. 物理架构设计
物理构架更关注物理上的基础设施，例如：系统、网络、服务器等，常见问题有HA、可伸缩
如何部署架构，选择不同的部署方式，从而达到可靠性、可伸缩性、持续可用性、性能、安全等要求
2.6. 五视图法架构设计步骤
总体上，五视图法做架构设计的步骤是逻辑架构->数据架构->开发架构->运行架构->物理架构
- 理清业务之后可以画出领域模型
- 根据领域模型进行数据架构设计
- 数据结构定好后，确定技术栈等开发架构
- 分析好功能性需求，把关运行架构
- 最终成型后落地计划，设计物理架构
架构设计往往是从逻辑架构开始
- 分析和确认需求
逐步开始开展开发架构与数据架构的设计
- 软件分层、分包、技术框架，以及部分质量属性
- 数据库设计
对于一些关键性功能进行运行架构设计
- 性能、可伸缩性、可靠性、安全性
往往后期逐步开始考虑物理架构设计
- 服务器、网络、安装部署等等