Dynamic 开发人员如何让业务用户定义应用程序逻辑？

我正在工作中开发一个新的应用程序，一位经理正在推动业务规则管理系统（BRMS）和工作流管理系统的概念，我正试图找出集成这些类型工具的最佳方法

关于这些类型的系统，我不知道我不知道什么，所以我试图获得其他的观点和信息

经理需要的是业务用户能够在不需要开发人员时间（或最少开发人员时间）的情况下更改业务规则或流程流

当我考虑如何将BRMS融入代码时，BRMS对我来说更容易理解。这非常简单，我可以看到逻辑如何完全驻留在应用程序之外。由于我对这些类型的系统没有做过太多的工作，我希望能提供与.NET集成的优秀产品的信息，或是体验方面的信息。（我们正在查看InRule、Blaze Advisor和ILOG规则）

我不太确定的是工作流部分

工作流基础对我来说是有意义的，因为它是一个已知的、定义为集成在应用程序代码中的工作流，但是管理者并不是在寻找基础，而是想让业务用户定义和更新工作流。任何允许最终用户动态创建工作流的系统类型对我来说都没有什么意义

我被要求看一个工作流引擎的例子。在我看来，它看起来是完全独立的，除非开发人员编写.NET代码与后端系统接口

我可以理解一个工作流系统，它允许用户定义特定的、有限的操作，如“电子邮件某某”和“需要某某批准”，但我不知道应该动态定义应用程序流的工作流系统如何集成到应用程序中，甚至我刚才描述的更简单的系统如何显示和更新后端数据

我正在推动使用案例，以便更好地理解我的经理在将这些类型的逻辑移到应用程序代码之外方面所寻求的，但同时，我希望任何人都能提供关于这些类型系统的信息。正如我所说，我不知道我不知道什么，我们的业务用户似乎认为我们的新应用程序应该支持这些类型的工具。我想确保由于缺乏知识而限制了我们的功能

---

谢谢您提供的任何信息或建议。

如果您在.NET.NET工作流基础中工作。这很复杂，是真的，但它是免费的，并且有你的经理要求的一切。业务规则部分将需要一些习惯，工作流将需要一些初始投资来构建您自己的“环境”，但是，当您从上面看这一切时，WF.NET仍然提供了比其他人提供的更多的功能。InRule是一个便宜的产品，它不能做很多事情，Blaze太复杂了，太贵了，对“非程序员”来说也不合适；ILOG也不是针对“业务用户”的。

工作流基础的问题是，微软改变了WF 3和WF 4之间的规则（体系结构），也没有第三方工作流活动的市场（市场已死），这意味着没有编程就没有可扩展性。（这消除了不雇佣程序员就使用解决方案的想法）。另一方面，市场可能没有提供比WF更好的解决方案（即其他解决方案更差）。“即其他解决方案更差”-阿门：尤金一针见血，非程序员无法修改WF工作流。还有，为什么你说Blaze不适合非程序员？“我看过的演示让制定规则看起来很容易。”亚历克斯。我在一家大型旅游公司工作，该公司在FICO Blaze上花费了约30万美元，主要是因为他们的演示和销售人员明确表示“不需要程序员”。不过，他们并没有告诉您，要在Blaze中成功地处理现实生活中复杂的规则和内容，您的业务人员必须学习类似“cusom”JS的语言。这是一个真正的表演停止。现在，一年后又有三个“工作流”产品，我们正在WF环境中工作。不完美，偶尔需要一些编程干预，但仍然比我们尝试的其他方法更好。因此，我最初的职位。