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

需求分析

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

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

设计原则

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

架构与架构图

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

架构图的分类

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

传统架构图

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

UML类图的六大关系

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

你可能感兴趣的:(学习笔记,需求分析,java)