Business rules, today and after the multi-tenancy line moves

Scene 7: Business rules today

Below the interface are the business rules: how each customer's policies, approvals and workflows apply the product's capabilities. They vary from customer to customer, and mature products let customers adjust many of them through configurable workflows, which vendors say cover most common scenarios. When a customer needs something the workflows cannot express, there is no middle option. Either the configuration exposes a value for it, or it becomes an engineering change to code every tenant runs on. A special case in shared code does the most harm in the business rules, because a change made for one customer can surface as a defect for another.

Scene 21: business rules and invariants

Then the business rules, which a brownfield programme reaches later, if at all. The language expresses each customer's rules in the domain's own terms, over the invariants: which entities exist, how they relate, and which workflows govern them. A customer's variation becomes that customer's own business rules, checked against the invariants, and the shared code stays as it is. The existing APIs may not offer the granularity the language needs, but they already cover a large part of the domain. Deciding what becomes an invariant is architectural judgement.