工作流与任务

    基于工作流的系统架构是一种常见的通用的系统架构。通过工作流步骤的组合满足业务流程的配置和变动。每个步骤之间要么是共享数据，要么是传递参数，来支持工作流引擎实现步骤间的调用；因此下一步是知道上一步处理结果，不论是下一步的参数初始化还是下一步读取共享数据。

    基于任务的系统架构是与基于工作流类似的系统架构；任务分为定时任务、(条件触发)一次性任务（链）、（ForkAndJoin的）复合任务等。任务从形态上比较类似工作流的步骤，通过共享数据，基于状态机实现业务逻辑。与工作流相比，任务的组合更加灵活，因为任务之间是没有关系的--即使复合任务，也不过是为了方便任务的管理，完全可以将其分解为独立的任务，利用独立的状态机实现其业务逻辑。

    独立的任务集带来了更好的并发性，不再遵循业务请求个数与执行线程数相当的惯例；例如这样的业务场景：在处理业务逻辑的事务结束后，需要短信通知用户；并将处理结果同步到客服系统。工作流模式大约需要三个步骤完成；而任务模式的一种实现是创建三个任务，短信通知任务、同步数据任务可以并发执行；另一种方案是在处理业务逻辑的任务结束时，创建另外两个任务即可。并发不止用于这些事后通知、同步的实现，还可以用于业务数据的准备、可并发的数据操作等。

    任务的颗粒可大可小，从系统架构层面看，一个子系统可以是一个任务，它从运行之后，就按照while(true){}的模式在运行；遇到满足条件的数据就进行处理，否则就休眠；这个层面类似工作流的步骤，只是没有系统真的会这么实现。划分任务颗粒的大小是重要设计目标，以封装、并发为出发点。一个业务对象的处理封装在一个任务链中。与其他业务对象的交互通过创建新任务、事件、消息等方式触发。这里所指的业务对象不是单一的数据或者数据集合，而是承载一项业务的数据集合。工作流的步骤更多是基于逻辑封装、复用的考虑划分的；它更注重事务、异构系统、代码复用。

    有利有弊，基于任务的系统架构必须有清晰的状态机驱动，但状态机隐藏在代码实现中；工作流模式隐含了状态机在步骤间的跳转中，但可以通过BPMN转化的图形UI清楚看到状态机。虽然两者可以进行混搭，必然以工作流为主导，形成了无入参的步骤。我觉得这样不可取，根据主要目标选择合适的架构，是系统架构师的责任，混搭不是不可以，关键看：是有清晰的目标，进行有机的融合，产生积极有效的作用。

    最后说说这两种模式在测试方面的差异：以工作流为核心的系统，如果其步骤间的分界非常清晰，则很难对步骤进行单元测试，即，要求步骤是面向接口开发；以任务为单元的测试则相对清晰很多，因为开始时就标定了清晰的状态机和执行条件。当进行集成测试时，两者不相伯仲，测试难度都略大。