如何把流程图转换为软件设计(初稿)

摘要: 本文探索的是一系列把流程图转换为软件设计的步骤

大致步骤分为:

1. 用户需求(读懂原型图, 消化业务知识)
2. 产品功能
3. 流程图
4. 领域设计 (彩色建模+ DDD领域模型)
5. 知识转换: 消化业务知识是否成功在于是否能够把明显的已知条件转换为隐含的有助于软件设计的条件
6. 实体设计/聚合根设计
7. 接口交互设计
8. 编写代码

粗浅理解: 第1,2步不是很熟悉, 这与用户洽谈有关系.因此不是本文的重点; 本文着重是在描述如何在确定了符合业务需求的产品功能以及梳理清楚流程之后如何去根据流程图建立领域模型.

1. 如何根据业务流程去画出建立领域模型呢?

这里可以使用的工具是UML彩色建模

• 红色: 过程数据(moment interval) 某个过程的产物–用于记录动作的
  它们在未来会转换成一张或者多张数据库表,
  在系统初始化时通常是空表

• 绿色: 自然数据(party, place, thing) 人? 地点
  问题域中涉及到的"参与者(人, 公司等)",
  “地点”,“东西(物品,服务)”. 在识别自然数据时
  还需要考虑是否引入"角色".
  它们在未来也可能会转换为一张或多张数据库表
  而且系统初始化时通常会有基础数据, 也会随着系统应用而不断增加记录
  特点: 具有唯一标识, 可以根据这个唯一标识去追踪它.
  (这是领域建模中的实体的概念么?)

• 黄色: 角色数据(role)-- 把绿色的自然数据抽象出来而形成角色

• 蓝色: 描述类数据(description)
  分为两类:一类是概述类, 如为了方便选择商品,抽象了品类这个概述性名称;
  二是规则类, 即想使用数据库表配置的相关规则
  它也可能会转换为数据库表, 且在系统初始化时就有内容, 且会不断改变
  它是无唯一标识的
  (这是值对象的概念么)

识别数据的先后顺序:
红 --> 绿, 黄 --> 蓝

具体步骤如下:

0. 先把流程描述中的名词画出来

1. 对着业务流程识别出不同的过程(需要考虑全面):
   如体检业务中分为 开单过程 预约过程, 缴费过程, 进行体检项目

2. 每个过程都应该找出对应的过程数据, 用红色标识

3. 把每个过程数据的关系: 依赖, 聚合, 一对多, 多对多的关系标识出来

4. 然后从最核心的过程数据的那个类开始, 即找出关系最多只想的那个类
   先从这个类开始找自然数据

5. 这个过程数据上有人参与么?
   有人生成它? 或者它被人接收? 识别出来之后 有团体么? 他们的关系是如何的? 聚合? 一对多? 角色之间可以互换么?(如果要可能有继承关系, 如果不用那么就单独列出来),
   这些人中, 有需要抽象成角色么? 比如 服务人员可能会换岗么?这些人需要分成不同角色吗? 如果是角色, 应该有什么人来扮演这个角色?

6. 把步骤5中的核心问题: 有人吗? 有东西吗? 有地点吗? 这些考虑点转移到另外一个过程数据对应的实体去逐一考虑, 把剩下的所有的过程数据都这样考虑个遍, 就完成了识别绿色和黄色的任务了

7. 接着来考虑描述性数据(即蓝色)
   分为概述类和规则类
   在流程描述中有哪些类是为为了方便用户使用的有概述功能的?
   概述类: 如体检套餐–> 概述类的名称, 用来方便用户选择体检项目的
   在流程描述中 有哪些规则是适合用数据库表配置的呢?
   规则类: 如积分规则, 折扣规则

用这种方法画出类图是比较好画的

–

2. 这个彩色建模建立出来的实体就是全部么?
如何识别出聚合根? 哪些是值对象?

**- 何谓聚合根? **
每个聚合都有一个根实体（聚合根，Aggregate Root），这个根实体是聚合所表述的领域概念的主体，外部对象需要访问聚合内的实体时，只能通过聚合根进行访问，而不能直接访问。

• 关于如何寻找聚合根, 这篇文章介绍得很详细:
  http://www.cnblogs.com/netfocus/p/3307971.html
  在此引用几个关键点:

  聚合是用来封装真正的不变性，而不是简单的将对象组合在一起；
  聚合应尽量设计的小；
  聚合之间的关联通过ID，而不是对象引用；
  聚合内强一致性，聚合之间最终一致性；

结合上面的描述个人的理解是:

静态的类图可以画出来, 根据流程识别出用户意图,即理解当前的需求和结合接下来的计划的需求–> 圈出聚合根, crud操作都是通过聚合根的id去导航而操作, 而非直接对聚合根内的非聚合根实体去操作–> 定接口(这就是所谓的领域服务么?)–> 设计交互过程: 设计的一些技巧(设计模式应该用到的技巧, 比如工厂模式, 装饰者模式等等, 因此而变得鲜活)–> 这些都体现在很多优秀的开源项目中, 其源码的都写法都是遵循设计的,而最终都是源于这个开源项目想要实现什么样的功能.这种类型的项目就是高级项目, 就是类似于Apache社区所支持的项目,

总体思路就是以上这个过程, 其中关键的关键在于如何定出聚合根,符合业务需求或者项目的目标的聚合根.而业务需求难度在于人与人之间的沟通难点是否清晰, 含混不清的需求定义增大难度.能够阐述清晰这些业务需求的定义, 有个共同的业务术语系统, 会有助于项目初期阶段进行, 这一步界定也是最关键的, 毕竟需求不准确, 后续麻烦就多了. 一旦这些界定清晰了, 接下来就是聚合根内部的实体应该如何组织成为一个整体了, 而组织方法关键是看如何合理地运用23种设计模式了, 这其中的过程也挺有趣的. (其中用得最多的就是用工厂模式去组织聚合根)

聚合根的概念是跟用户意图有关, 即跟需求有关. 它是不是可以这样那样聚合, 就跟用户是否要查询它出来非常相关.
(用户需求可以被拆分成一个个用户意图,)
用户意图用户需求就决定这个聚合根如何去划分.
什么样的实体或者值对象会被划分到同一个聚合里面组成聚合根呢?

–

• 关于业务建模

对于toB的业务建模是站在企业的视角去考虑问题, business need是最主要驱动力
而互联网思维是站在个人需求的角度上, 难度比ToB的大大增加,对于并发的要求很高, 而Apache社区的项目的目标就是服务这种类型的.

–

• 关于技术的进阶

读论文, 得啃.

4.如何确定业务流程

1. 业务流程名称
2. 流程简要说明: 描述流程的起点和终点以及目标概述
3. 业务流程描述, 选择合适的模型呈现业务流程的分析结果.
   流程图的六个要素:
   分工, 活动, 协作, 产物关系, 分支, 审批

• 具体的实例可以参考以下链接
• http://www.cnblogs.com/daoqidelv/p/7657785.htm

参考资料
http://www.cnblogs.com/netfocus/p/3307971.html

http://www.cnblogs.com/daoqidelv/p/7657785.htm
<领域驱动设计：软件核心复杂性应对之道>
<实现领域驱动设计> 美 弗农著