孤尽T31训练营-架构设计-Day1

需求分析

理解和挖掘用户的诉求、以及背后的逻辑，转化成可行性的分析结果。从非结构化到结构化，确定系统的职责、模块的过程。
边界、用户故事、用户路径

• 分析背后的人性：人性是提出需求的本源
• 需求产品化：模块化、配置化、有逻辑
• 需求落地路径：
  需求分析->可行性->设计->编码->测试->发布
  伪需求：没有调研、没有目标、没有逻辑的无脑需求
  应对：1、用数据化结果否定需求合理性
  2、用正反案例来说明需求需要改进的地方
  3、用户路径和触点推演需求合理性
  权利需求：老板或者是强势业务方的需求
  应对：1、先肯定需求价值再提出需求实现的成本
  2、给出更好的需求替代方案
  3、从数据和案例角度说明需求快速上线危害性
  问题的分层
  (本源问题) 用户问题：“我想支付”
  (经营视角) 业务问题：支持一切可以支付的第三方支付工具
  (体系结构) 产品问题：支付需要逆向流程、异常流程、对账模块等
  (架构代码) 技术问题：高并发、可用性，实现第三方支付的链路
  KISS原则
• 如何让我们的系统由可扩展性和可维护性
• 如何让我们的系统能够恰到好处地解决问题
• 如何让我们的系统能够运行3-5年不重构
  DRY原则
  Don’t Repeat yourself
  重复代码的危害性：
• 不一致性
• 代码冗余
• 易出BUG

设计原则

• 单一职责原则
• 里氏替换原则
• 接口隔离原则
• 组合复用原则
• 依赖倒置原则
• 迪米特原则
• 开闭原则

架构与架构图

什么是架构

• 架构是一种能力，而不是一个职位
• 架构=组成+决策
• 组成=模块结构+模块关系
• 决策=约束+设计原则+演化方向

架构图的分类

• 业务架构
• 应用架构
• 数据架构
• 技术架构

传统架构图

• 物理视图：和部署相关的架构决策（一般不画）
• 逻辑视图：设计满足功能需求的架构（逻辑结构图）
• 开发视图：设计满足开发期质量属性的架构（UML图）
• 处理视图：设计满足运行期质量属性的架构（UML图）
• 场景视图：需求分析技术，通常采用UML的用例图进行设计

UML类图的六大关系

• 泛化关系：即继承关系
• 实现关系：实现接口
• 聚合关系：业务上整体与部分可以分开，是关联关系的特例
• 组合关系：业务上整体与部分不可以分开，同样是关联关系的特例
• 依赖关系：只要在类中用到了对方，就存在依赖关系
• 关联关系：体现的是业务逻辑的关系，是依赖关系的特例，具有导航性&多重性