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

问题描述

我在一家年轻的银行公司工作.我们的解决方案(.NET)具有重要的技术债务，因此我们遵循DDD原则对其进行重构.我们计划使用(a)业务规则引擎.业务规则处理会计目的，营销目的，风险目的，法律事务……我们计划对BRE进行POC，由业务发起.

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吗?
• 您认为采用独特的BRE是否可以满足所有领域的需求， 还是为每个域设计定制解决方案的原型更好?
• 常见的陷阱是什么?

• Are there tools to manage the BR repository?
• Is there any pattern that might help to separate processes and BR ?
• Do you know some authors who wrote about migrating a solution to a BRE ?
• Do you think adopting a unique BRE can fit the needs for all domains, or is it better to prototype a custom solution for each domain ?
• What are common pitfalls ?

谢谢

推荐答案

所以，这有点麻烦，但是我还没有看到业务规则引擎在生产环境中能很好地工作.我唯一看到它们运行良好的地方是当它们被完全视为要替换的代码存储库时.

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屋！