Domain primitives, the invariants, today and after the multi-tenancy line moves

Scene 8: Domain primitives today

Beneath the business rules are the domain primitives: the entities, calculations and relationships every customer relies on. In payroll, that means an employee, a pay element, a statutory deduction, and how they combine. They change far less from one customer to the next. Two customers can have different pay policies while sharing the same definition of a pay element. The product exposes these primitives through its APIs, which already cover a large part of the domain.

Scene 11: The domain invariants

Look back down the stack. The deeper the layer, the fewer customers need to change it. Almost every customer customises something: in one survey, only 7% changed nothing. Far fewer go deep, and most of what changes sits near the top. Under the business rules are the domain primitives, and they do not vary between customers. Call them the domain invariants. They are where correctness is decided, and what the revenue depends on. The domain invariants are the product's core value. So the architecture needs a layer that holds those invariants, with everything that varies built on top of it. A product's knowledge graph already records the invariants: its capabilities, workflows and entities, and nothing specific to one customer. That is the idea behind semantic engineering.