和
前面的章节一样，我们先从一个故事开始，这个故事和晚饭有关。在我家，周一至周五，老婆做饭，我洗碗。每天做完饭，老婆会叫我到厨房，说，看，这个盘要洗
一下，另外，灶台脏了，也要擦。如果放在以前，我会说，好，明白了。但是现在，程序员的生活让我意识到，沟通永远不是一件简单的事情，我说，好，知道了。
等等，这个故事和本章的主题
-数
据模式有一毛钱的关系？这只是一个关于沟通的故事。是的，让我们稍微映射一下：这里，晚饭这个流程包含了两个基本的任务，分别是做饭和洗碗，在做饭这个任
务完成时，任务的执行者（老婆）向下一个任务的执行者（我）传递了数据（要洗哪些东西），正如语言是人之间的沟通方式一样，数据是
IT系统之间的沟通方式，语言之间的沟通总是最有效的，数据交互却未必，因为
IT系统里的数据交互除了让计算机理解外重要的是还需要人理解，
IT系统是对现实生活的映射，也正因为如此，现在数据之间的沟通也在向语言靠拢即语义化（
REST/语义网）。
好，言归正传。
在
前两章里，我们分别讨论了工作流的控制模式和资源模式，控制模式关注于如何合理调配业务流程里的任务，从而获得理想的执行效率和收益；资源模式则关注于如
何合理调配可用的资源来执行业务流程。本章将介绍工作流系统里的数据模式，从数据的角度分析工作流系统对数据的处理。数据模式共计
39种，在下面的介绍中，我们将这些模式分为了四部分，分别是数据可见性、数据交互、数据传输和基于数据的路由。
本章先会概要重复一下与数据模式相关的一些基本概念，例如流程定义、流程实例、原子任务、块任务等。接下来会对具体的
39种数据模式进行讨论，讨论的模式按照应用、描述和实现展开，分别对应着实际场景对模式的映射、模式的介绍和工作流系统对该模式的实现支持。最后是小结。
一、基本概念
1、工作流系统里的流程结构
在正式介绍数据模式之前，让我们先简单回顾一下工作流系统里流程的基本结构。
图
6-1 工作流系统里的流程结构
流程定义
：对业务流程的建模和描述，其具有足够的细节信息，能够直接被工作流系统所执行。典型的，流程定义由一系列的任务组成，这些任务以图形的形式展现并被连接起来。
流程实例
：流程定义的一个执行实例被称为流程实例。一个流程定义可以存在多个同时执行的流程实例。这些流程实例互相独立执行。
任务
：一个任务对应着流程定义里的一个单一工作单元。存在四种不同类型的任务：原子任务、块任务、多实例任务和多实例块任务。
原子任务包含简单且独立的任务定义，当其初始化时只会产生一个可执行的任务实例。
块任务是一系列任务的组合，典型的，工作流系统里存在的子流程任务（节点）即是块任务，当一个块任务开始执行时，其将流程控制权传递给与之对应子流程的第一个任务，当子流程完成执行后则将控制权返回给块任务。如图
6-1所示，块任务
C对应着一个由任务
X、任务
Y和任务
Z组成的子流程，实际执行时，任务
C会触发任务
X的执行，任务
Z执行完毕即子流程执行完成后则会触发任务
C执行完成。
多实例任务在实际执行时会产生多个并行执行的任务实例，这些任务实例一般互相独立执行。当一定数量的实例执行完毕后即会触发后续任务的执行。
多实例块任务结合了块任务和多实例任务的定义，其在实际执行时产生多个任务实例，每个任务实例对应着一个子流程实例。
任务实例
：任务的一个执行实例。
2、数据相关约定
我们使用
def var ${变量名
}定义数据元素，同时
def var
${变量名
}的声明位置决定了变量的作用范围。如图
6-1所示，我们在任务
C上定义了一个名为
M的数据变量，其的作用范围为任务
C，任务级别。
我们使用
use(${变量名
})表明对变量的使用；使用
pass(${变量名
})表明数据变量的传递。在图
6-1里，变量
M从任务
C传递至任务
E。
对于变量的数据类型，典型的有
String、
integer、
float、
boolean、
date、
time等，很多工作流系统使用序列化和反序列化支持存储任意类型的数据类型，如数组、集合、对象。
3、类比的约定
在后续对各个模式的介绍里，我会围绕一个项目团队的故事进行映射，我们如此约定：
流程定义：
我们认为所有成熟的软件公司都会建立起其完整并适用的一套软件开发流程，我们将这套流程看作是这里的流程定义。
流程实例：
围绕着软件开发流程，我们会使用这套流程来开始我们实际的软件开发项目，我们将所有的软件开发项目都看作是开发流程的执行实例，即流程实例。
任务：
项目开发过程中的各项任务。
数据：
我们将团队成员之间的信息交流看作是数据交互。