一、架构设计概述

架构是一种能力，而不应该定义为一个岗位[格局.jpg]

需求分析

边界 - 是否需要进行开发（可否用已有的）
用户故事 - 具体用户使用的场景（想要支付）
用户路径 - 使用功能的具体流程（打开支付宝点击收付款，要尽量短）
从用户目的出发，而不是完全按照用户说的做

辨别伪需求

用实际历史实行案例
用正反例
实际推演
肯定需求，再提出更好的替代方案（面向老板）

需求记录：
1. 用户通过网站注册并登陆
2. 车次、车厢、经停站、时刻表增删改查
3. 修改个人信息
4. 乘客管理
5. 余票查询
6. 创建（票）订单
7. 第三方支付（支付宝）
8. 支付成功通知（mock）

问题分层

用户问题（本源问题）：我要买世界上性价比最好的牙刷
业务问题（经营视角）：我们给他提供咱最能赚钱的性价比差不多的牙刷
产品问题（产品问题）：啥叫最能赚钱，啥叫性价比差不多，他买了退货怎么办（注意逆向流程）
技术问题（技术问题）：用什么框架实现搜索，去哪抄个性价比算法

设计原则

1. 单一原则：属性和行为向着模块预定义的功能内聚（根据模块名）
2. 开闭原则：对扩展开放对修改关闭（识别隔离变化点）
3. 里式替换：父类能出现的地方子类一定能够出现
4. 依赖倒置：接口的粒度尽可能小，同一接口的方法强内聚于同一特征
5. 接口隔离：细节依赖抽象
6. 迪米特：互相了解的信息尽可能少（只关注输入输出，不需关注实现）
7. 组合复用：继承是绑定关系，组合相对较为松散（只暴露给用户必要的方法，减少误用概率）

画架构图

架构类别

1. 业务架构：业务单元划分边界
2. 应用架构：系统的层次、开发原则、各个层次的应用服务
3. 数据架构：根据系统应用场景对数据进行处理（数据异构、读写分离、走缓存）
4. 技术架构：根据识别到所需的技术进行选型，描述关键技术以及之间关系

技巧

1. 布局：使用上下前后方位表示模块关系
2. 颜色：用明色表示核心
3. 逻辑：组件间的依赖关系

传统架构图

1. 物理视图：部署相关
2. 逻辑视图：逻辑结构图（对象模型，组件关系，约束以及边界）
3. 开发视图：保证开发期质量，开发环境下的静态组织（时序图，状态图）
4. 处理视图：保证运行期质量（描述系统的并发和同步方面的设计）
5. 场景视图：描述系统的参与者与功能用例间的关系，反映系统的最终需求和交互设计

具体图的类别

1. 类图：核心类的属性以及类与类间的关系
2. 时序图：关注正流程，不写逆流程、异常判断、分支判断