8
去工作流还是不去工作流？
我负责一个开发人员团队，他们将要开始开发轻型保险理赔系统。该系统涉及许多手动任务和业务工作流，我们正在研究使用Windows Workflow（.NET 4.0）。 业务领域的示例如下：保单持有人致电联系中心提出索赔。此“事件”触发两个子任务，这两个子任务是手动并行执行的，可能需要很长时间才能完成； 检查客户是否存在欺诈行为–一种手动过程，操作员可以通过该过程调用各种信贷公司来检查和评估欺诈客户的潜力。在这里，子任务可以输入许多子状态（检查中，参考检查失败，参考检查通过等） 将项目发送到维修中心–手动过程，将保单持有人提出索赔的项目发送到维修中心进行修复。从此处，子任务可以输入许多子状态（等待修复，进行中，已修复，已发布等）。仅当每个子任务的状态达到预定义的状态（基于业务规则）时，索赔才能继续进行。 从表面上看，Workflow确实是最好的技术选择。但是我在使用WF 4.0时确实有些担心。 技能集–查看平均开发人员技能集，我看不到许多了解或了解工作流程的开发人员。 可维护性–社区内部对WF 4.0项目的支持似乎很少，并且再加上缺乏技能集，引发了人们对可维护性的担忧。 进入障碍–我感到Windows Workflow的学习曲线很陡，而且拿起来并不总是那么容易。 新产品–由于Workflow已针对.NET 4.0进行了完全重写，因此我将该产品视为第一代产品，可能没有必要的稳定性。 声誉–以前的工作流版本不受欢迎，被认为难以开发，并且导致业务采用率低。 所以我的问题是，在这种情况下我们应该使用Windows Workflow（WF）4.0，还是有替代技术（例如，简单状态机等）使用甚至更好的工作流引擎？