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!
