将业务规则与业务流程分离
如何从业务流程中外部化业务规则，以便可以在不触及业务流程逻辑的情况下添加规则？
例如，我有两个业务流程，“添加产品”和“更新产品”，这两个流程共享一些通用规则，并且以后可以不断添加规则。我打算编写一次业务流程，它执行特定流程可用的所有规则，如果没有抛出异常，则继续成功完成业务流程。
我不打算使用规则引擎，因为我认为这对于我的架构来说可能太重了。
谢谢和问候，
阿杰
how do I externalize the business rules from the business processes so that I can add rules without touching the business process logic?
For example, I have two business processes, say "Add Product" and "Update Product", there are a few common rules that these 2 processes share, and rules can keep getting added later. I intend to write the business process once, which executes all the rules available for a particular process, and if no exception is thrown, continues to complete the business process successfully.
I do not intend to use a rules engine as I think this might be too heavy for my architecture.
Thanks and Regards,
Ajay
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这个问题的答案比我在这里写的要复杂。这涉及数据关系科学、安全性、政策原则以及您的企业/行业的管理约束。
如果您的意思不是“业务规则”和“业务政策”那么模糊，我可能会误解您的问题。
The answer to this question is more complicated than I could write here. This touches on the sciences of data relations, security, policy doctrine, and administrative constraints of your business/industry.
I could be misinterpreting your question if you meant something less vague than "business rules" and "business policies".
您可以使用多种技术将规则与流程流程分开。在某种程度上的抽象，您从业务流程中的各个点调用“方法”。然后问题就变成了可以在不改变业务流程本身的情况下修改该方法的机制之一。
人们可以将该方法打包到自己的库（dll、jar 或其他库）中，并用新版本替换该 jar。改变图书馆，改变业务规则。
人们可以用从数据库获得的可配置参数来表达该方法中的逻辑。改变数据库，改变业务规则。
如果复杂性足够高，您会发现您已经实现了自己的规则引擎。
在某些时候，使用现有的规则引擎比重新发明轮子会更有效。
如需更详细的建议，您需要告诉我们更多有关您正在做什么的信息。
You can separate the rules from the flow of the process with many techniques. At some level of abstarction you are calling a "method" from various points in your Business Process. The question then becomes one of the mechanisms by which that method can be modified without changing the Business Process itself.
One could package the method in its own library (dll, jar or whatever) and replace that jar with a new version. Change the library, change the business rules.
One could express the logic in the method in terms of configurable paramteres obtained from a database. Change the database, change the business rules.
If the complexity rises enough you find that you have implemented your own rules engine.
At some point it becomes more efficient to use an existing rules engine rather than reinventing this wheel.
For more detailed advice you need to tell us more about what you are doing.
问题非常广泛，所以我将按照一般模式回答。
在许多情况下，我所做的就是定义流程，以便在流程的适当阶段插入许多“看门人”活动。每个看门人都负责执行业务规则的特定子集。例如，这样的一项活动可能会增强数据质量。另一种可能会根据业务规则做出路由决策。另一个定价。等等。
实际规则本身保存在工作流外部，并且可以独立于工作流进行修改。诀窍是限制规则评估的“过程结果”，以便可以继续拥有可预测（和可测试）的过程。
The questions is quite broad so I will answer in terms of a general pattern.
What I have done in many cases is to define the process such that one inserts a number of "gate-keeper" activities at appropriate stages in the process. Each of these gate-keepers is responsible for enforcing a particular sub-set of the business rules. So, for example, one such activity might enforce data quality. Another might make a routing decision based on business rules. Another pricing. And so on.
The actual rules themselves are held external to the workflow and can be modified independently of it. The trick is to constrain the "process consequence" of the rule evaluation so that one can continue to have a predictable (and testable) process.