1. 项目介绍

31天完成一个类似于12306的售票网站、核心的业务：

1. 从查票、下单、支付、通知的主流程
2. 抽象商品、订单、支付的核心模型
3. 处理票务异常和日志

项目目的: 了解架构设计背后的方法论，全面提升代码能力、设计能力、交付能力和协作能力

2. 需求分析

2.1 需求分析的目的

理解和挖掘用户的诉求、以及背后的逻辑，转化成可行性的分析结果。从非结构化到结构化，确定系统的职责、模块的过程
分析背后的人性： 人性是提出需求的本源
需求产品化： 模块化、配置化、有逻辑
需求落地的路径： 需求分析  -> 可行性 -> 设计 ->编码 -> 测试 -> 发布

2.2 如何确定真需求与伪需求

举例子：
    伪需求：没有调研、没有目标、没有逻辑的无脑需求
    应对：1、用数据化结果来否定需求的合理性
         2、用正反案例来说明需求需要改进的地方
         3、用户路径和触点推演需求合理性
    伪需求：老板或者是强势业务方的需求
    应对：1、先肯定需求价值，在提出需求实现的成本
         2、给出更好的替代方案
         3、从数据好案例角度说明需求快速上线的危害性

2.3 T31项目需求大致的内容

用户通过网站注册并登陆
车次、车厢、经停站、时刻表、增删改成
修改个人信息
乘客管理
余票查询
创建（票）订单
第三方支付（支付宝）
支付成功通知

3.设计原则

3.1 单一原则

一个类应该只负责一项功能，如A类只负责功能A，B类只负责功能B，不要让A类既负责功能A，又负责功能B，这样会导致代码混乱，

以下反例：发送短信的接口实现类中，出现了发送邮件的方法，不利于后面维护与排查，应该可以在写一个发送邮件的接口类

3.2 里氏代换原则

父类能够出现的地方，子类一定能够出现，而子类出现的地方，用父类去代替，一般都会有问题，

以下反例：

3.3 接口隔离原则

接口的粒度尽可能的小于同一接口的方法强内聚于同一特征

3.4 组合复用原则

尽量使用合成/聚合的方式，而不是使用继承

3.5 依赖倒置

高层模块不应该依赖底层模块，二者都应该依赖其抽象
底层依赖于高层

3.6 迪米特原则

对象应该对其他对象保持最少了解
迪米特法则又叫做最少知道原则，即一个类对自己依赖的类知道的越少越好，也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部，对外除了提供的public方法，不对外泄露任何信息。

3.7 开闭原则

开闭原则是编程中最基础、最重要的设计原则。
一个软件实体如类、模块和函数应该对扩展开放（对提供方）。对修改关闭（对使用方），用抽象构建框架，用实现阔炸细节。
当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

4.架构与架构图

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

4.1 架构的目的

确定系统的边界，在技术层面上做与不做
确定系统里各模块的依赖关系与模块的宏观输入输出
使用后续的子系统或模块设计在一个既定的框架内和技术方向上继续演化
明确非功能性需求，非功能性需求是指安全性、可用性、可扩展性等

4.2 什么是架构图

水平面上的业务模块 + 垂直平面上的技术模块的互相依赖，形成的逻辑结构图

4.3 如何画架构图

1. 搞清楚要画的架构图的类型
2. 确认架构图中的关键要素（比如产品、技术、服务）
3. 梳理关键要素之间的关联： 包含、支撑、同级并列等
4. 输出关联关系清晰的架构图

4.4 架构图的分类

业务架构图

使用一套方法论，对所涉及到的业务单元进行边界划分熟悉业务
比如： 团购网站系统 -> 商品类目、订单服务、支付、退款等进行清晰划分

应用架构

对整个系统的实现进行可视化落地实践，系统的层次/开发原则/各个层次的应用服务，一般为垂直依赖型 比如: 团购网站系统 -> 数据层、服务层、通讯层、展现层

数据架构

是一套对存储数据的架构逻辑，根据各个系统应用场景、不同时间段的应用场景，对数据进行诸如数据异构、读写分离、缓存使用、分布式数据策划等划分

技术架构

承接应用架构的技术需求，并根据识别的技术需求，进行技术选型，把各个关键技术和技术之间的关系描述清楚

4.5 传统架构图

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

4.6 UML图

统一建模语言，使用图形和符合描述软件模型中的各个元素
UML图的分类
静态结构图： 类图、对象图、包图、组件图、部署图 动态行为图 交互图（时序图与协作图）、状态图、活动图

4.7 类图的的六大关系

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

T31项目架构笔记