项目开发过程中如果均是简单的数据请求与返回，那么方法调用和业务逻辑是最容易处理的，根据入参返回数据即可，数据的生命周期始于请求，终于数据返回，没有其他。
倘若特定需求场景需要多个接口协作完成一件事，数据流转存在多路由，业务逻辑处理将会呈现复杂化，朴素的数据流控制方式就是定义数据中间态通过硬编码形式来影响数据流向，这种设计在复杂度不深的情况下总是很容易实现，开发成本和沟通成本较低，也不失为一种非常有效的开发设计方式。而随着业务场景复杂化，流程变更频繁，开发人员会在之前得益的简单设计上发现维护和可拓展性极差，甚至陷入流程泥潭中难以自救，最直接的表现就是接口交互定制化，所有的交互看不到任何业务或故事主线，所有的服务交互都需要最原始的那些开发人员的文档、注释甚至“言传身教”的指导才可以洞察复杂业务的其中一二，这是软件开发中的技术负债和不完善，我们急需一个可以引导完整业务流程的体系或者框架来引导服务交互，来驱动业务数据流转，对数据的出生、中转、停留及最终消亡进行有效控制和监管，让服务有源可溯，有序可遵。关于以上概述都是为了引申出下面项目实践的利器，工作流。
关于工作流开源框架，一般有JBPM和Activiti，简单检索了下两者对比如下：
Activiti持久层通过MyBatis实现、与Spring融合支持事务，与当前项目技术背景较为符合，且上手较为便捷，参考资料广泛，学习成本较低，加上之前个人项目运用过Activiti前身，对PVM设计模式有一定了解，最终决定采用Activiti作为工作流来进行开发。
关于Activiti工作流的具体内容这里不做赘述，本文的核心放在Activiti工作流与业务结合的实践，下面是Activiti工作流的一些特点：
目前负责的项目是一个关于用户认证相关的业务，简单描述认证业务流程如下：