Separation of business rules with business processes

Question

How can I derive business rules from business processes so that I can add rules without touching the logic of business processes?

For example, I have two business processes: Add Product and Update Product, there are several general rules that these 2 processes share, and the rules can continue to be added later. I intend to write a business process once that fulfills all the rules that are available for a particular process and, if no exception is thrown, continues to successfully complete the business process.

I do not intend to use the rule engine, as I think it might be too hard for my architecture.

Thanks and respect,
Ajay

Answer 1

The answer to this question is more complex than I could write here. This applies to the sciences of data relations, security, the doctrine of politics and the administrative restrictions of your business / industry.

I could misinterpret your question if you had in mind something less vague than "business rules" and "business policies."

Answer 2

You can separate the rules from the process flow by many methods. At some level of abstraction, you invoke a “method” from different points in your business process. Then this question becomes one of the mechanisms by which this method can be changed without changing the business process itself.

You can pack the method into its own library (dll, jar or something else) and replace this jar with a new version. Change the library, change the business rules.

One could express the logic in the method in terms of configurable parameters obtained from the database. Modify the database, change the business rules.

If the complexity is too high, you will find that you have implemented your own rule engine.

At some point, it becomes more efficient to use the existing rule engine rather than reinvent the wheel.

For more detailed recommendations, you need to tell us more about what you are doing.

Answer 3

The questions are quite broad, so I will answer in general terms.

What I have done in many cases is to define the process so that one inserts a series of gate-keeper actions at the appropriate stages of the process. Each of these custodian keepers is responsible for following a specific subset of the business rules. So, for example, one of these actions can ensure data quality. Another may make a business rule-based routing decision. Another price. And so on.

Actual rules themselves are stored outside the workflow and can be changed independently. The trick is to limit the “consequence of the process” to evaluating the rule so that a predictable (and verifiable) process can continue.