T31项目笔记-架构分析

本文详细介绍了T31项目,类似于12306的售票网站,重点探讨了需求分析的步骤和问题解决策略,如KISS原则和DRY原则。同时,文章阐述了7大设计原则,包括单一职责、里氏替换、依赖倒转等,旨在提升软件的可扩展性和可维护性。此外,文章还讨论了架构的目的和架构图的绘制,强调了UML在建模中的作用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

1. T31项目介绍(类似于12306的售票网站)

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

T31的需求分析

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

一、需求分析

1、什么是需求分析

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

这里用户的诉求是重点,如果满足不了用户的诉求,做再多也没用。

2、需求分析关注的3个点

边界:分析背后的人性,人性是提出需求的本源。区分哪些需求是已经实现了的,可以复用功能或者调用其他系统的接口来实现,来确定需求的边界。

用户故事:形成最终能够还原用户角色的用户故事。比如T31里的购票、候补买票、为了接朋友查余票。这些都是用户故事,从用户角度区分不同场景,仔细理出来,就是用户故事。

用户路径:用户和系统的任何触点,都算用户路径。确定用户的意图,仔细描述清楚整个过程,并且在设计时尽可能让这个触点少。这样用户的使用成本就会很低。

3、需求分析中会遇到的问题以及解决方法

工作中遇到伪需求该怎么办?比如用户什么都想要,要得不正确的需求。(没有调研、没有目标、没有逻辑的无脑需求)

应对方案:
① 用数据化结果否定需求合理性
② 用正反案例来说明需求需要改进的地方
③ 用户路径和触点推演需求合理性
权利需求(老板或者

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值