20211026 架构设计笔记

一、T31项目介绍

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

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

本次购票系统的需求分析

 

二、需求分析

1、什么是需求分析

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

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

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

 

 

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

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

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

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

1. 工作中遇到伪需求该怎么办？比如用户什么都想要，要得不正确的需求。（没有调研、没有目标、没有逻辑的无脑需求）

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

2. 权利需求（老板或者强势业务方的需求）该怎么办？

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

   目的在于迂回引导出自己想要表达的想法方案。

4、辅助需求分析的方法

4.1、问题的分层

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

4.2、KISS 原则

Keep it “simple” and “smile”

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

如何让我们的系统有可扩展性和可维护性 如何让我们的系统能够恰到好处地解决问题 如何让我们的系统能够运行3-5年不重构 有支付 就会有付钱（正向流程）和退钱（逆向流程）

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

业务部门的挑战（价值问题） 成本部门的挑战（ROI问题） 测试部门的挑战（可测试性） 技术部门的挑战（可行性和工期）

4.3、DRY原则——Don’t Repeat Yourself

一切重复的代码都可以抽象，重复代码的危害性:

1、不一致性

2、代码冗余

3、易出BUG

三、7大设计原则

七大设计原则 共同点︰提升软件的可扩展性，可维护性是抽象思维和归纳思维的集中体现 本次项目的重点实践点： 1、类图设计 2、接口设计 3、组合设计

1、单一职责设计原则

（SRP：Single responsibility principle）

单一职责原则表示一个模块的组成元素之间的功能相关性。从软件变化的角度来看，就一个类而言，应该仅有一个让它变化的原因；通俗地说，即一个类只负责一项职责。它是一个简单又直观的原则，但是在实际编码的过程中很难将它恰当地运用，需要结合实际情况进行运用。单一职责原则可以降低类的复杂度，一个类仅负责一项职责，其逻辑肯定要比负责多项职责简单。

核心：高内聚、低耦合的延伸

反例：

 

2、里氏替换原则

（LSP：Liskov Substitution Principle） 核心：里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。

里氏替换原则的重点在不影响原功能，而不是不覆盖原方法。

3、依赖倒转原则

（DIP：Dependence Inversion Principle） 定义：高层模块不应该依赖低层模块，二者都应该于抽象。进一步说，抽象不应该依赖于细节，细节应该依赖于抽象。

核心：依赖倒转原则的核心思想就是面向接口编程

4、开闭原则

（OCP：Open Closed Principle） 开闭原则，在设计一个软件系统模块（类，方法）的时候，应该可以在不修改原有的模块（修改关闭）的基础上，能扩展其功能（扩展开放）。 核心思想 对扩展开放，对修改关闭。即在设计一个模块的时候，应当使这个模块可以在不被修改的前提 下被扩展。 扩展开放 某模块的功能是可扩展的，则该模块是扩展开放的。软件系统的功能上的可扩展性要求模块是 扩展开放的。 修改关闭 某模块被其他模块调用，如果该模块的源代码不允许修改，则该模块修改关闭的。软件系统的 功能上的稳定性，持续性要求是修改关的。

5、接口分离原则

（ISP：Interface Segregation Principle） 接口隔离原则，真正的意图是 分离 接口（接口的功能）

接口隔离原则强调：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。 接口的粒度尽可能地小同一个接口的方法强内聚于同一特征 例子：

6、组合/聚合复用原则

（CRP：Composite Reuse Principle） 核心：尽量使用对象组合，而不是继承来达到复用的目的。该原则就是在一个新的对象里面使用一些 已有的对象，使之成为新对象的一部分：新的对象通过向这些对象的委派达到复用已有功能的目的。 复用的种类：继承和合成聚合 在复用时应优先考虑使用合成聚合而不是继承 聚合组合是一种 “黑箱” 复用，因为细节对象的内容对客户端来说是不可见的。

7、迪米特原则

（LOD：Law of Demeter） 迪米特法则又称为：最少知道原则，它表示一个对象应该对其它对象保持最少的了解。通俗来说就是，只与直接的朋友通信。

（类间解耦，低耦合）意思就是降低各个对象之间的耦合，提高系统的可维护性；在模块之间 只通过接口来通信，而不理会模块的内部工作原理，可以使各个模块的耦合成都降到最低，促 进软件的复用

对于被依赖的类来说，无论逻辑多么复杂，都尽量的将逻辑封装在类的内部，对外提供 public 方法，不对泄漏任何信息。

类与类，类和接口，接口和接口之间的关系： 实现关系（一个类实现一个接口）和 泛化关系（一个类继承另一个类）

四、架构

1、什么是架构？

架构是一种能力，而不是一个职位，它不是让你能做什么而存在，而是为了不让你做什么而存在的。所以我们在解读框架架构时，更需要了解它为什么这么设。

架构 = 组成 + 决策 组成 = 模块结构 + 模块关系 决策 = 约束 + 设计原则 + 演化方向

 

2、架构的目的

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

五、架构图

1、架构图是什么？

架构图则是表达这种集合的载体，是水平的业务单元 + 垂直的技术单元组成的逻辑结构图

2、架构图的作用是什么？

将目标系统的结构可视化，通过直观的方式描述技术思维，减少沟通障碍，提升协作效率，划分目标系 统的边界。

3、如何画出架构图

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

该项目的架构图：水平层面的业务模块 + 垂直层面上的技术模块 依赖形成的图称为架构图

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

4、架构图的好与坏

布局：图形的上下左右前后6个方向的位置关系 颜色：视觉中心在哪里，哪些元素被忽略 逻辑：组件之间的依赖，业务实现的可行性

5、架构图的分类

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

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

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

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

6、什么是UML——Unified Model Language（统一建模语言）

定义： Unified Model Language Unified：说明以前不统一 Model：建模往往需要抽象 Language：交流，为什么能交流，定义共同的协议 统一建模语言，使用图形和符号描述软件模型中的各个元素和它们之间的关系

6.1、UML的分类

静态结构图：类图、对象图、包图、组件图、部署图

动态行为图：交互图（时序图与协作图）、状态图、活动图

6.2、类的六大关系

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

组合 比 聚合 关系更强——聚合关系弱，组合关系强（组合图中箭头是黑色的）

六、T31项目

1、类图 类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他 类的关系等。 项目核心：票 核心服务：订单

 

2、时序图 通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作

 

七、24个设计模式

创建型： 单例模式、简单工厂、模式工厂、方法模式、抽象工厂模式、建造者模式、原型模式

结构型： 代理模式、适配器模式、装饰器模式、桥接模式、组合模式、享元模式、外观模式

行为型： 观察者模式、模板方法模式、命令模式、状态模式、职责链模式、解释器模式、中介者模式、访问者模式、策略模式、备忘录模式、迭代器模式