架构设计学习笔记
1. 需求分析
任何系统的设计，都离不开其特定的业务场景，也就是需求分析。需求分析的目的，是为了弄清楚该系统在完成一件什么事情，主要回答为什么要做这个系统，以及这个系统是什么样子等问题。
1.1 一句话描述什么是需求分析
理解和挖掘用户的诉求，以及背后的逻辑，转化成可行性的分析结果。从非结构化到结构化，确定系统的职责、模块的过程。
1.2 确定需求的三个要素
边界、用户故事、用户路径。分析需求，其本质上就是分析背后的人性，通过确定边界、用户故事、用户路径，进而使得需求具备产品化、模块化、配置化。
2. 设计原则
2.1 KISS原则 keep it simpe and smile
2.1.1 simpe
理念：大道至简，设计系统的目的就是要解决一定的业务或者非业务问题，那么我们就可以先思考下面这几个问题：
- 如何让我们的系统有可扩展性、可维护性？
- 如何让我们的系统能够恰到好处的解决问题？
- 如何让我们的系统能够运行3-5年不重构？
2.1.2 smile
系统需要有很强的协调能力，保持微笑，面对各种否定 价值问题、成本问题、可测试性问题、可行性和工期问题
2.2 DRY原则
一切重复的代码都可以抽象
2.3 七大设计原则
23种设计模式，其背后都是在实践七大设计原则，目的就是提高系统的可维护性、可扩展性等特点。 提升软件的可扩展性、可维护性是抽象思维和归纳思维的集中体现
- 单一职责原则
- 里氏替换原则
- 接口隔离原则
- 组合复用原则
- 依赖倒置原则
- 迪米特原则
- 开闭原则
3. 架构
3.1 什么是架构
- 架构=组成+决策
- 组成=模块结构+模块关系
- 决策=约束+设计原则+演化方向
3.2 架构的目的
- 确定系统边界，在技术层面上做与不做
- 确定系统里各模块之间的依赖关系与模块的宏观输入与输出
- 使后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化
- 明确非功能性需求，非功能性需求是指安全性、可用性、可扩展性
3.3 为什么要画架构图？
架构图是表达集合的载体，是水平的业务单元+垂直的技术单元组成的逻辑结构图。 架构图的作用是，将目标系统的结构可视化，通过直观的方式描述技术思维减少沟通障碍，提升协作效率，划分目标系统的边界。
3.4 画架构图
画图的步骤：
- 明确要画的架构图的类型
- 确定架构图中的关键要素
- 梳理关键要素之间的关联
- 输出关联关系清晰的架构图
3.5 架构图的分类
- 业务架构图
- 应用架构图
- 数据架构图
- 技术架构图
- 传统架构图
3.6 UML 统一建模语言
- 静态结构图：类图、对象图、包图、组件图、部署图
- 动态行为图：交互图（时序图与协作图）、状态图、活动图
3.7 UML类图的6大关系
- 泛化关系：即继承关系
- 实现关系：实现接口
- 聚合关系：业务上整体与部分可以分开，是关联关系的特例
- 组合关系：业务上整体与部分不可以分开，同样是关联关系的特例
- 依赖关系：只要在类中用到了对方，就存在依赖关系
- 关联关系：体验的是业务逻辑的关系，是依赖关系的特例，具有导航型、多重性
3.8 时序图
通过描述对象之间发送消息的时间顺序显示多个对象之间的动态 协作。
- 关注正常流程
- 不关注逆向流程
- 不关注异常流程
- 不关注分支判断
例子：T31购票系统
通过分析12303购票系统的核心需求，练习画系统关键类图、时序图
需求描述与简单分析：
需求中的名词
客户（普通用户）、铁路部门管理员、车厢、经停站、时刻表、火车票、乘车人
需求中的动词
注册、登录、修改信息、实名认证、代购、余票查询、购买车票下单、支付
分为三大块功能
- 移动端系统：普通用户相关的基本操作（注册、登录、修改自己的基本信息、实名认证）
- 移动端系统：普通用户购买车票支付的操作（余票查询、添加乘车人、选择车次乘车人座位类型后下单、订单支付）
- 后台管理系统：铁路部门管理员的管理操作（用户管理、角色管理、菜单管理、车次车厢等信息的管理）
