Reactors#

A customer's payments are put on hold, and the unresolved invoices need to be flagged for review. A new invoice arriving tomorrow needs the same treatment. If applying the rule depends on each application remembering to run the review mutation, another way of adding invoices can miss that step. The business rule then depends on the route by which information entered the dataset.

Standing rules#

A reactor runs a stored mutation as a standing rule when data changes. The invoice review rule can apply when the customer's payment restriction changes or when another unresolved invoice appears. The responsibility belongs with the dataset, so each application can record the information it knows without reproducing every consequence. New applications can participate without independently implementing the review policy.

A review flag expresses something the application has concluded from other facts. Keeping that conclusion current is work the team would otherwise have to coordinate across the applications that can change those facts. Reactors provide a place for that responsibility alongside the rule itself. A query can then select the resulting information for an investigation view or payment workflow.

Evolution#

The review policy remains part of the dataset. If the team adds an amount threshold, that revision belongs to the mutation's history just like any other change to a definition. People can examine the rule and how its meaning developed alongside the invoices it concerns. Automatic changes still need review, especially when several applications rely on their effects.