A way or pattern for implementing a business rule engine in a solution?
I work for a young banking company. Our solution (.NET) has an important technical debt, so we are refactoring it around DDD principles. We plan to use (a) the business rules engine. Business rules relate to accounting goals, marketing goals, risk goals, legal materials ... we plan for POC BRE to be sponsored by the business.
I'm looking for some feedback from people who have succeeded in taking BREs, or a combination of BREs?
- Are there tools to manage the BR repository?
- Is there any pattern that can help separate processes and BR?
- Do you know some of the authors who wrote about porting a solution to BRE?
- Do you think adopting a unique BRE can meet the needs of all domains, or is it better to prototype your own solution for each domain?
- What are the common mistakes?
Thank,
source to share
So, this is a bit of a rant, but I have yet to see the business rule engine work very well in a production environment. The only time I've seen them work well is when they are handled exactly like the code repository they replace.
They have to follow the SDLC, go through requirements collection, development (with engineers), QA, and finally progress to production.
Rule engines are commonly sold to business people as ways to get around the costs of development, testing, and source code management. These systems usually fall apart in a fairly short time. Rules are the logic of programming, the fact that they are loaded from the database somewhere instead of being loaded from the filesystem doesn't change anything. As a programming logic, the people most suited to develop them are ... programmers.
When business people try to write these things, they tend to get frustrated pretty quickly when the system doesn't stop them from creating logical holes that the flow gets into. About what programmers are used to thinking.
It's really a matter of loyalty. You are trading a high definition programming language (java, c, python), for a low precision language. You are not magically reducing the number of decision points. You are simply trying to express them in a language that is bound to be more limited. When you try to express your more complex problem in low-truth language, you create a monster. With hundreds or thousands of rules linked to each other. If only one or two people can understand this, he will soon become a huge responsibility to the organization.
Your company may be different, but I've seen this happen several times and usually the only way out is to break and rebuild. I've seen business processes work well enough. Things that just coordinate the gates of the lower level at a pretty high level. But it leaves all real decisions on lower-level machines. They also need to be kept in their place and have viable progress, qa, etc.
source to share