Select Page

Guidelines for Organizing Business Rules

by | Mar 10, 2020

In irAuthor, as with most software with structured logic, when you decide to implement a new application or a new addition to an existing application, you must make several decisions:

  • What will my rules do?
    • What are the intended inputs and outputs of these rules?
    • Are they tied to a specific data model?
    • Do they involve 1:1 or 1:∞ relationships (which involve using different techniques)?
  • How should I write my rules to do this? Apart from getting the logic right, should I strive for…
    • …efficiency?
    • …clarity?
    • …the ability to scale the rules easily as my requirements expand?
  • When will my rules do this?
    • As part of a manual process?
    • If automated, when will the entire rule application be called during the solution design?
  • Where do I need to put these rules? At what entity context, and within what kind of rule set structure for organizing?

Many of these questions ultimately lead to another, deeper question: Once I’ve completed a portion of my rules, how should they be organized? That’s the topic I intend to take on here with some broad guidelines I’ve accumulated from over 5 years of authoring rule applications for more than 50 customers.

Considerations for Logic Placement

There are a number of factors that will influence where you put your rules, but these general guidelines should help you with better rule application design. Keep in mind that there are exceptions to every piece of guidance listed below, but you should find this guidance useful.

 

Consideration Where to Put Logic Exceptions
Output: if your rules intend to change the values of one or more child entity fields At the entity level of the child containing the changed fields If your logic is limited in scope, consider placing it at a parent level instead
Business logic Business logic should be grouped by meaningful business processes Overlap between meaningful business processes may cause you to reevaluate this
Operational logic To the extent practical, place logic which drives the flow of the rule application in its own rule sets If your operational logic is limited or cannot be easily segregated, it can be included in business rule sets
Repeated, identical logic In a separate explicit rule set; alternatively, use vocabulary templates in existing rule sets If repeated logic can be either a) passed in as configuration data, or b) looked up from a table, consider those options
Minor utility functions Calculated fields within the entity structure; alternatively, use vocabulary templates in existing rule sets If this logic needs to be made more visible, move to rules and initialize variables in a language rule
Richer output messaging with multiple fields of data A separate entity and rule sets related to that entity A structure like this might not apply to smaller rule applications
Validation logic A separate rule set(s) at the entity level of the fields being validated Minor amounts of validation logic can and should be placed within business rules
Logic whose results will not be directly passed back in the rule application results Use variables in the rule set or temporary fields on the entity to store results n/a

 

Hopefully this list of general guidelines is helpful as you build out and refine your rule applications. If you have further or deeper questions about any of the topics or recommended above, please contact the ROAD Services team at [email protected]. Happy authoring!

 

BLOG POSTS BY TOPIC:

FEATURED ARTICLES:

STAY UP TO DATE

We’d love to share company and product updates with you! Please enter your email address to subscribe to monthly updates from InRule. 

If at any time you want to unsubscribe, you can easily do so by clicking “unsubscribe” at the bottom of every message we send or visiting this page.