Business rules have been around a long time. Ritc rules, besides being actionable, conform to an architecture that is as flexible as it is sturdy.
Ritc rules follow these principles:
- Rules are grouped within apps
- Rules contain triggers and actions
- There can be multiple triggers, and multiple actions
- Triggers can be chained – based on the parameters you use
- Parameters are passed – and accumulate – so as to be available to each subsequent trigger or action
- Triggers generally request responses to REST APIs (microservices) by reference to a Channel and a Channel Function
- Actions also use REST APIs (by reference to a Channel and a Channel Function), and generally use the http verbs POST, PUT, PATCH, or DELETE to perform their work
- Rules and apps can be related in hierarchies
- Rules can be added and removed without breaking the application
- A rule can be ‘run’ individually.
- Alternatively, you can ‘run’ an app, in which case all active rules within that app are attempted.
Composable apps are facilitated because triggers can also refer to other Ritc apps you have built (‘sub-apps’), creating a hierarchy. You can consider a rule that does this to be ‘multi-layered’.
Rules are powerful things.