T31-Day02架构概念

Day2

一、项目介绍

1.T31项目名称由来

• T31是杭州-北京的特快车次名，自1978年8月1日起开行，已于2019年1月5日停运
• 对应了训练营标题T31，31天31个人(内院)
• T31的T对应了单词ticket票务，我个人觉得也可以理解为火车train，火车由一节节车厢连接而成，就像我们的代码由各个模块衔接起来后有序稳定且快速的运行。

2.项目功能

T31是一个类似与12306的售票网站，涵盖查询、下单、支付、通知整个购票流程。同时系统功能上模块化商品，订单，支付，对购票异常做相应保护和监控。

3.项目目的

以实战演练达到提高代码、设计、交付和协作的能力

二、需求分析

什么是需求分析

理解和挖掘用户的需要、和它背后的逻辑，转化为具有可行性的分析结果。

需求落地的路径

需求分析->产品设计->架构设计->编码->测试->发布

需求角度

• 用户视角：目的我想去从杭州去北京，需要购买一张车票。
• 业务视角：支持更多的支付渠道
• 产品视角：除主流程外各种分支细节，例如 退票，订票异常等情况。
• 技术视角：高可用，高可扩展，满足业务拓展需求。

如何应对伪需求

1. 通过数据化否定需求合理性，例如通过用户人群划分确认某个功能只满足5%的用户，但是会影响到60%的用户造成不好的体验。
2. 用户路径推演需求合理性，例如增加这个需求后用户需要更繁琐的操作达到使用目的。
3. 针对权力需求首先要态度上肯定，行为上通过用户数据实际案例和开发成本等多方维度说明利害关系最后即使上线也能轻松“甩锅”。

三、架构

架构解释

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

架构的目的

确定系统边界，明确业务需求和非功能性需求。根据项目需求对技术上做出取舍使后续子系统或模块的开发设计在一个既定的框架内和技术方向发展，保证项目的可维护性，可扩展性。

架构图

架构图是表达架构的载体，是水平的业务单元+垂直的技术单元组成的逻辑结构图。它将目标系统的结构可视化以减少沟通障碍，提升协作效率。

架构图分类

业务架构

使用一套方法论对涉及的单元进行边界划分。 例如：购票系统划分出订单、支付、用户 等模块

应用架构

对整个系统的实现进行可视化落地实践，系统的层次/开发原则/各个层次的应用服务 ，比如我们常画的三层架构 数据层 、服务层、展示层。

数据架构

对数据存储的架构逻辑。 (ps:这块不是很了解，也没接触过)

技术架构

承接应用架构需求，对技术进行选型，描述清楚关键技术之间的关系。

常用UML图 (Unified Model Language)

• UML类图（class diagram）

  显示模型的结构，标记出核心类、类的成员、类之间的关系。
  

• UML活动图（Activity Diagram）

  如果说类图是结构建模工具，那么活动图就是行为建模工具，活动图是表达复杂业务流程的工具，它帮助我们理清思路、发现问题。一个活动图只表示一件事情的“经过”，不要指望一个活动图表达很多流程。

• UML顺序图（Sequence Diagram）

  描述对象之间发送消息的时间顺序显示多个对象之间的动态协作，时序图只关注正常流程，不需要关注逆向、分支、异常等特殊情况。

• UML用例图（Use Case Diagram）

  用例图表达的是 执行者(Actor) 能做什么事情（Use Case)。
  

四、模块设计

七大原则

1.单一职责（Single Responsibility Principle）

高内聚低耦合的延申， 属性和行为向着模块预先定义的功能内聚

2.里氏替换（Liskov Substitution Principle）

简单来说父类出现的地方子类一定可以替代但是反过来则会有问题，LSP是关于继承机制的应用原则，是实现开放封闭原则的具体性规范，如果违反了里氏替换原则那么必然违反 开放关闭原则。

3.接口隔离（Interface Segregation Principle）

使用多个小的专用接口，而不要使用一个大的总接口，接口应该是内聚的，应该避免出现胖接口。

4.组合/聚合复用原则（Composite/Aggregate Reuse Principle）

继承是一种绑定关系就像父子，组合是一种松散的合作关系就像恋爱。

5.依赖倒置(Dependence Inversion Principle)

通过抽象机制有效解决层级之间的关系，降低耦合的粒度，实现对抽象的依赖。细节依赖抽象，底层依赖于高层。

6.迪米特原则(Law Of Demeter)

互相了解的信息，尽可能的少，使用一个接口只关注输入和输出不关注具体实现。

7.开放-封闭原则（Open-Closed Principle）

对看扩展开放，对修改关闭。封装变化是实现开放封闭原则的重要手段，对于经常发生变化的状态需要将其隔离出来。