Method or pattern to implement a Business Rules Engine in a solution?

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.

I am looking for some feedback by people who succeded in adopting a BRE, or, a combination of BREs?

• 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 ?

Thanks,

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.

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.

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.