在解决方案中实现业务规则引擎的方法或模式? [英] Method or pattern to implement a Business Rules Engine in a solution?

问题描述

我在一家年轻的银行公司工作.我们的解决方案 (.NET) 有一个重要的技术债务，因此我们按照 DDD 原则对其进行重构.我们计划使用 (a) 业务规则引擎.业务规则涉及会计目的、营销目的、风险目的、法律问题……我们计划 POC BRE 由企业赞助.

I am working in a young banking company. Our solution (.NET) has an important technical debt, so we refactor it following DDD principles. We are planning to use (a) Business Rules Engine(s). Business rules deal with accounting purposes, marketing purposes, risk purposes, legal stuff... we are planning to POC the BRE to be sponsored by the business.

我正在寻找成功采用 BRE 或 BRE 组合的人的一些反馈?

• 是否有管理 BR 存储库的工具?
• 是否有任何模式可能有助于将进程和 BR 分开?
• 您是否认识一些写过将解决方案迁移到布雷?
• 您是否认为采用独特的 BRE 可以满足所有领域的需求?还是最好为每个域设计一个自定义解决方案原型?
• 常见的陷阱有哪些?

谢谢，

推荐答案

所以，这有点啰嗦，但我还没有看到业务规则引擎在生产环境中运行良好.我看到它们运行良好的唯一一次是当它们被完全视为它们正在替换的代码存储库时.

So, this is a bit of a rant, but I have yet to see a business rules engine work very well in a production environment. The only time I've seen them work well is when they are treated exactly like the code repository that they are replacing.

他们需要遵循 SDLC，经历需求收集、开发(与工程师一起)、质量检查，最后升级到生产.

They need to follow a SDLC, going through requirements gathering, development (with engineers), QA, and finally promotion to production.

规则引擎通常作为绕过开发、测试和源代码管理成本的方式出售给业务人员.这些系统通常会在很短的时间内崩溃.规则是编程逻辑，事实上它们是从某个地方的数据库加载而不是从文件系统加载的，这一事实没有任何改变.作为编程逻辑，最适合开发它们的人是……程序员.

Rules engines are usually sold to business people as ways to bypass the cost of development, testing, and source-code-management. These systems usually fall apart in pretty short order. The rules are programming logic, the fact that they are loaded from a database somewhere instead of being loaded from a file system changes nothing. As programming logic, the people most suited to develop them are... programmers.

当业务人员尝试编写这些东西时，如果系统没有阻止他们制造流程陷入的逻辑漏洞，他们往往很快就会感到沮丧.程序员习惯思考的事情.

When business people try and write these things, they tend to get frustrated fairly quickly when the system doesn't keep them from making logic holes that the flow falls into. Things that programmers are used to thinking about.

这真的只是保真度的问题.您正在用高保真编程语言(java、c、python)换取低保真语言.您并没有神奇地减少决策点的数量.你只是想用一种必然更受约束的语言来表达它们.当你尝试用低保真语言表达更复杂的问题时，你最终会创造一个怪物.成百上千条规则串连在一起.只有一两个人能够理解它，它很快就会成为组织的巨大负担.

It's really just a matter of fidelity. You are trading a high-fidelity programming language (java, c, python), for a low-fidelity language. You are not magically making the number of decision points smaller. You are just trying express them in a language that is necessarily more constrained. As you try and express your more complex problem in a low-fidelity language, you will end up creating a monster. With hundreds or thousands of rules daisy-chained together. With only one or two people able to make sense of it, it soon becomes a huge liability to the organization.

也许你的公司不一样，但我见过这种情况发生过几次，通常唯一的出路是报废和重建.我见过运行良好的业务工作流引擎.只是以相当高级的方式协调低级逻辑部分的事物.但是将所有真正的决策留给了较低级别的机器.但是，这些也需要保留在原位，并进行可行的推广、质量检查等.

Maybe your company is different, but I've seen this happen a few times, and usually the only way out is to scrap and rebuild. I've seen business workflow engines that work fairly well. Things that just coordinate the lower level logic pieces in a fairly high-level way. But leaves all the real decision making to the lower level machinery. These too though, need to be kept in their place, and have viable promotion, qa etc.

这篇关于在解决方案中实现业务规则引擎的方法或模式?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！