以下例子只是抛砖引玉，千万不要因为下面的几个例子将思路锁死
1.为业务扩展灵活性而使用多引擎
在WF的引擎中可以同时运行多个工作流模板的多个实例，如图
这是一种理想的模式，但在实际开发中可能会有如下问题：
1.不同的工作流对持久化服务，监听服务的要求有同
2.不同的工作流对流程的控制要求不同，如CallExternalMethodActivity与HandleExternalEventActivity与宿主有比效复杂的交互操作。不同的状态机工作流有各自的业务状态操作
3.系统发布后，需要添加新的工作流模板。
等许多要求如果者使用上图的单引擎模式，代码将十分混乱，也不便于扩充
这时，可以使用下面的方式（当然这只是一个例子，具体开发中封装粒度可以随意调整）
2.为特殊的结点使用专用引擎
为特殊的结点使用独立的引擎的例子很多，在这里我只举一个简单的
在有些开发中，工作流的某个结点可能要与外部调备进行交互，如开关同一台电闸
NET中支持多线程，WF也可以并行实例，可以我们的电闸X并不支持多线程操作
我们不希望A流程实例与B流程实例同时对电闸X下手，我们也不希望A或B流程的两个实例同时对电闸X下手,
这时，可以使用双引擎，第一个引擎正常运行所有实例，当遇到[操作电闸X]结点时，将实例交给一个串行引擎(ManualWorkflowSchedulerService服务),由串行引擎逐个完成每个实例的[操作电闸X]结点，当然还可以在这个串行引擎中进行资源调用优化，优先级设置，开关闸状态共享等管理。要文就不讨论了.
3.物理双引擎
目的很明确，负载均衡与故障转移，与写SQL Server的思路一样，这里就不重复了,如图:
4.分存式引擎
这个是我以前的一个设想模式，但在其他工作流平台上不容易实现，不过在WF中确是很爽的。
技术特点如下：
1.使用智能客户端模式开发
2．所有的客户端都安装net 3.0 或使用Vista操作系统
3．将业务操作的用户UI直接封装到客户户端程序中
4．多用户参与的工作流，在某个用户的客户端运行完该用户的业务操作后，将实例传行化后以(TCP,WebService,或电子邮件)的方式发给下一个要参与流程的用户.
以前做过一个类似的，不过客户端的业务逻辑是在代码中推的，严格上说不能算工作流，
MS要将WF预装在每台电脑上，真不错，可以实现很多以前很难开发的功能了