实在睡不着，就继续说说关于工作流的一些事。
早上发了一篇关于工作流系统中业务数据和流程数据的理解，两者是相互关联着，缺了谁都不可能成为一个完整的业务流程。我想说的是，两者之间是需要相互了解，也就是说流程数据需要业务数据来进行一些操作，而业务数据又需要流程数据来提供一些信息。
一个工作流系统是否能够灵活方便的开发业务功能，业务数据处理能力的灵力性很是关键，或许对于一个简单的审批流，比如公文、申请等不会涉及太多的业务处理，顶多就是申请人填写表单，通过预定的流程路由在各个节点中流转，而节点实例就是对应的任务，逐步的进行审批，最后生成一个结果。这是很简单的流程应用，复杂一点的话，比如在某些任务节点中涉及到业务数据的计算、根据条件进行业务数据的批处理，流程正常结束后进行数据入库、信息归档，中断后进行消息通知等，各种各样的业务处理都会挂接在流程的流转过程中，而流程仅仅是一个设定好的路程，就像公路，具体的加油、或者别的动作都需要人为来处理。对于领域的核心业务，我们要将它们整理成代码，因为流程不可能为我们做任务除了流转外的其他事，这就需要流程能够在各种情况下都能进行数据处理，也就是业务操作接口。
在这里重点想要说的就是这个业务操作接口，在流程中哪些关键点应该能够支持。在这里其实可以联想一下微软的WF，它在活动的方法中就有涉及到前置函数以及后置函数，这就是为业务处理提供的接口，同理，我们也可以想象，流程实例在创建时以及结果时也应该能够进行业务处理，更细的话在流程实例的各个状态变更时也提供接口来作预防。对于流程节点实例，前置函数和后置函数显得更为重要一些，在节点路由中，每个路由也应该涉及到前置和后置函数。可以看到，流程实例及节点实例在变化时就可能发生业务处理，这个点就是需要挂接业务的地方，也就是接口的开放位置。
刚才也提到，工作流并非简单的审批流，审批只是它的整个过程的描述，能够有效的、灵活方便的带动具体的生产经营过程中的业务才是更有意义的，特别是怎样能够更加方便的进行复杂的业务数据处理，是开发工作流系统需要考虑的重点。
对于流程数据和业务数据的关联，当业务数据是多张表时，我们通常都是将主表与流程实例关联，业务子表与主表进行关联。
在通常情况下，创建业务表时会习惯性的添加一些字段，比如创建人、创建时间，除此之外还喜欢添加一个业务状态字段，前面也说过，它非同于流程状态，也许一致，也许不一致，通过流程来驱动业务状态的变化，这样有时候能方便查询。对于在业务表中是否添加流程实例ID，这个应该按具体情况再定，毕竟各家的开发模式不同。