1、类的分析与设计
这可能是大多数研发同学比较熟悉的领域，经典的设计模式，类之间的关系，泛化，组合等。
但是类从哪里来呢？是从需求之中凭空产生？又或者突然灵光一闪，有了类的雏形？
对类的进行设计与分析之前，需要做的是找到他。
2、识别类
经历过业务流程，系统建模，我们终于来到了系统里面，来寻找类。我们所熟知的类有三种，边界类，控制类和实体类。
边界类是外部系统在系统内部的映射，借由边界类，系统和外部系统交互。所以一些接口请求，输入输出都属于边界类的职责。在仓配系统中，商城就是一个边界类，将外部系统转移到内部系统来，屏蔽了接口请求相关的细节。
控制类往往是体现用例流程，一般而言，一个用例就是一个控制类。
实体类则是系统的核心，实体类良好设计能够提高系统的复用程度，减低系统的复杂性。
3、找实体名词
知道了有这三个类还是不足够我们识别具体的类，识别具体的类需要去业务流程，系统流程，系统规约中经常出现的名词。
在上面的流程图中，订单，商城，设备，物流，用户是反复出现的名称，说明这些类必然存在。
找到这些业务实体，就是找到类的第一步。
4、找到属性
类的属性也不是凭空产生的，需要对业务实现有价值，用户不一定有姓名，在物流上下文中，用户的属性就只有 ID，收货地址。
找到那些对于系统实现必不可少的属性，放到正确的类中。如仓配系统中的订单，包含订单号，商品，用户。用户则有收件地址。
在仓配系统中，用户只有一个地址，在商城的系统中，用户则有多个地址，充分说明了，不同的上下文中，类的属性不是固定的。
5、找职责
从业务规则和约束中，可以找到一些实体应当有的职责，如订单，就有验证合法性的职责。
有时候，有些对象看起来信息很富裕，但是却没有什么职责，说明他是一个值对象，像上图中的用户和收件地址，我们不关心他的 id，只关心收件地址，收件地址就代表着这个用户。
6、状态机
找到类和对应的职责，对于一些主要的实体类，还需要设计出他的状态机，清晰的状态机能有效地厘清系统内的一些事件和状态，增强系统整体的健壮性。
仓配中的订单，从用户购买的待发货状态，到通知物流发货，再到实际发货，物流签收有一些列状态的演变。
网友评论