如何做面向对象设计（OOD）？
我们把OOD设计环节拆解细化一下，主要包含以下几个部分：
-
划分职责进而识别出有哪些类
根据需求描述，我们把其中涉及的功能点，一个一个罗列出来，然后再去看哪些功能点职责相近，操作同样的属性，可否归为同一个类。
-
定义类及其属性和方法
我们识别出需求描述中的动词，作为候选的方法，再进一步过滤筛选出真正的方法，把功能点中涉及的名词，作为候选属性，然后同样再进行过滤筛选。
-
定义类与类之间的交互关系
UML 统一建模语言中定义了六种类之间的关系。它们分别是：泛化、实现、关联、聚合、组合、依赖。我们从更加贴近编程的角度，对类与类之间的关系做了调整，保留四个关系：泛化、实现、组合、依赖。
-
将类组装起来并提供执行入口
我们要将所有的类组装在一起，提供一个执行入口。这个入口可能是一个 main() 函数，也可能是一组给外部用的 API 接口。通过这个入口，我们能触发整个代码跑起来。
如何做业务系统的需求分析与设计？
需求分析
- 要有一定的产品思维，站在产品的角度思考
- 懂得借鉴的力量，可以找类似产品对标学习
- 通过产品线框图、用户用例图/用户故事细化业务流程，挖掘容易漏掉的细节、功能点
系统设计
- 合理地将功能分到不同的模块
- 设计模块之间的交互关系
- tip：上下级之间倾向同步调用，同级之间倾向异步解耦调用
- 设计模块的接口、数据库、业务模型，实际上，业务系统本身的设计无外乎这三点：接口设计、数据库设计、业务模型设计。
如何做非业务的通用框架需求分析与系统设计？
需求分析
功能性需求分析
- 将不条理的、无逻辑的大段长串的原始需求描述（可能需要自己提炼，持续提炼），转换成条理性的、更容易理解的、罗列比较规整、分门别类的列表信息。
- 接触产品设计时用到的线框图，梳理整个流程，
挖掘隐藏需求，提前识别
非功能性需求分析
对于一个通用的非业务框架，一般需要考虑很多的非功能性需求，这里罗列如下：
-
易用性：易用性听起来更像是一个评判产品的标准。没错，我们在开发这样一个技术框架的时候，也要有产品意识。框架是否易集成、易插拔、跟业务代码是否松耦合、提供的接口是否够灵活等等，都是我们应该花心思去思考和设计的。有的时候，文档写得好坏甚至都有可能决定一个框架是否受欢迎。
-
性能： 对于需要集成到业务系统的框架来说，我们不希望框架本身的代码执行效率，对业务系统有太多性能上的影响。一方面，我们希望它是低延迟的（时间复杂度），也就是说不影响或很少影响业务本身的执行时间；另一方面，我们希望框架本身对内存的消耗不能太大（空间复杂度）
-
扩展性：这里说的扩展性跟代码的扩展性有点类似，都是指在不修改或尽量少修改代码的情况下添加新的功能。但是这两者也有区别。代码的扩展性，是从
框架代码开发者的角度来说的；这里所说的扩展是从框架使用者的角度来说的，特指使用者可以在不修改框架源码，甚至不拿到框架源码的情况下，为框架扩展新的功能。这就有点类似给框架开发插件 -
容错性：不能因为框架本身的异常导致接口请求出错。所以，我们要对框架可能存在的各种异常情况都考虑全面，对外暴露的接口抛出的所有运行时、非运行时异常都进行捕获处理。
-
通用性：为了提高框架的复用性，能够灵活应用到各种场景中。框架在设计的时候，要尽可能通用。（有SPI思维，但也要注意警惕过度设计）
个人总结的设计/落地技巧： 1.学会画图（线框图） 2.先找一个最简单场景，设计最小原型MVP并实现（注意，不要陷入到具体的实现逻辑，而是找到最简单，最快速的极简流程，否则容易掉入面向实现编程的陷阱），懂得万事开头难的道理，先迈出第一步非常关键。 3.画系统设计图（这一步感觉可以结合实际情况（是否已经明确？）明确可以放到第一步做，不明确则可以放到第二步之后，有了最小原型，再发散思考，补全全系统设计图）
