T31架构设计项目——Day1

T31架构设计项目

day1：2021-10-27

一、项目介绍

T31项目是类似于12306的售票网站

• 从查票、下单、付钱、通知的主流程
• 抽象商品、订单、支付的核心模型
• 处理票务异常和日志
• 了解架构设计背后的方法论
• 以战促练，全面提升代码能力、设计能力、交付能力和协作能力。

二、需求分析

核心：用户的诉求

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

分析需求的内容

• 项目 / 需求边界

  • 让研发、QA能够相对准确的在MRD阶段评估时间；
  • 确定产品的适用范围，性能要求，做到对产品的能力范围心中有数，也有优化方向。

• 用户故事

  • “ 用户故事” 是一份简要的意向声明，描述了为用户执行的操作的系统需要；
  • 用户故事是一种工具, 用于以开发人员和用户都能理解的方式定义系统的行为。用户故事将工作重点放在用户定义的价值上, 而不是功能分解结构上；
  • 例子：查看航班信息、查看检查我当前的电费计费率。

• 用户路径

  • 用户路径分析可以用来衡量网站优化的效果或营销推广的效果，以及了解用户行为偏好，其最终目的是达成业务目标，引导用户更高效地完成产品的最优路径，最终促使用户付费；
  • 所以对于路径的使用方式，要尽可能地简单，方便。

• 分析背后的人性：人性是提出需求的本源

• 需求商品化：模块化、配置化、有逻辑

• 需求落地路径：需求分析 -> 可行性 -> 设计 -> 编码 -> 测试 -> 发布

分析需求的必要性

伪需求：没有调研、没有目标、没有逻辑的无脑需求

应对措施

• 用数据化结果否定需求合理性；
• 用正反案例来说明需求需要改进的地方；
• 用户路径和储点推演需求合理性。

权力需求：老板或是强势业务方的需求

应对措施

• 先肯定需求价值再提出需求实现的成本；
• 给出更好的需求替代方案；
• 从数据和案例角度说明需求快速上线危害性。

项目需求分析

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

三、问题的分层

• 本源问题——用户问题：“我想支付”
• 经营视角——业务问题：支持一切可以支付的第三方支付工具
• 体系结构——产品问题：支付需要逆向流程、异常流程、对账模块等
• 架构代码——技术问题：高并发、可用性、实现第三方支付的链路

KISS原则

1. Keep it simpe and smile

架构的理念是大道至简：解决问题

• 如何让我们的系统有可扩展性和可维护性
• 如何让我们的系统能够恰到好处地解决问题
• 如何让我们的系统能够运行3-5年不重构

2. Keep it simpe and smile

现代软件需要很强的协调能力，保持微笑，迎接各种否定

• 业务部门的挑战——价值问题
• 成本部门的挑战——ROI问题
• 测试部门的挑战——可