Business Rules - state vs transition driven

Co-workers and I were recently trying to tease out whether our rules were event-based or state-based.  

  • Was the predicate, if clause, written to be based on an action that occurred, an event?  
  • Was the predicate, if clause, written based on the current state of the business data?
  • Were our rules a mix of event-triggered and state-driven?
We started poking at this with the business users. We showed them both styles and described the side effects.  It turns out our business users were thinking in a specific and simplifying way. This meant we could increase the reliability of our design by pushing rule definitions mostly into a specific style. 

Business Rules can be written in an unlimited number of ways and syntaxes.  We'll ignore most of that for this conversation and instead focus on how we define the if clause that determines if action is taken.


Transition vs State Based

Simple Example

A person loses their driving permit for a given state. It could be that this person let theirs expire or they moved to another state.  We can specify the rules in either a transition style or a state style.

Business Data Change Streams

Let us look at the notification streams that would trigger rule evaluation and execution.

The top image shows a notification stream tied to transitions. Each message describes a specific change. Every message must be processed.
The bottom image shows a bare notification stream. Each message tells the receiver something has changed and that they need to check it out to see if action must be taken. If rules can operate against the current value then in some cases it may be possible to skip a message with the assumption the state will be evaluated in some future message. This can be useful, where possible, in situations where a receiver falls behind or is down for some period of time.

Resiliency in Streaming Architectures

The Oder is may not be guaranteed in streaming data/messaging systems. This is especially true in highly partitioned systems with multiple consumers.   These two diagrams try and show change notifications that are streamed after some remote system has been updated. 

The CDC / transition oriented system has to be processed so that it stays in order.  This means buffering or some other control may have to be created in order to hold or re-sort incoming notifications.
Bare notifications that exist without any transition information may be processed in any order since they are all equivalent. None of them hold any transition information.  All of them query the data source to run their business process against the data in storage. It is assumed that the retrieved data is current.

Rule Targeting and Evaluation Patterns

Transition based rules tend to be more targeted. They happen when a specific state change occurs. 
State-based rules may need to be evaluated more often since they may apply at any time.  State-based rules happen whenever the state of the target changes. Only the rules will understand if they apply or not based on their left-hand side.

Example Message Differences

Event-driven systems based on Change Data Capture (CDC) events lend themselves to transition based rules. CDC often captures the before and after versions of some data change.  The data in CDC messages may not be enough to actually run the action/then side of a rule which means the business process may have to go look up other data.  The CDC may not be enough.  The order of CDC messages is important because the rules try and build some state by applying the CDC data.   This can cause problems if the lookups must see the other data as it was at the time of the change.  Some systems don't support this type of as of lookup which means rules run with a mix of older event data and newer reference data.
Event-driven systems can send minimalistic notifications that force the business rules to look at the data in the data store.  This means the rules always run against the current version of the data and not the data at the time of the notification.  This means an intermediate state may never have the rules run against that state. This is the desired behavior in many systems.


Transition based and State-based business rules each have their own advantages and disadvantages. The main purpose of this blog is to help you explicitly understand the types of rules you are using and may want to use in the future.

Created 2020/10


Popular posts from this blog

Understanding your WSL2 RAM and swap - Changing the default 50%-25%

Installing the RNDIS driver on Windows 11 to use USB Raspberry Pi as network attached

DNS for Azure Point to Site (P2S) VPN - getting the internal IPs