Ask a team building property software what their central entity is and they will almost always say the property. It is the thing with a photograph and an address, so it feels like the subject. But nothing meaningful happens to a property. Things happen to the relationship between a property, a landlord and a tenant over several years — and that relationship is the tenancy.
How to tell you have chosen wrong
- Answering an ordinary business question requires joining four tables and knowing which order events occurred in.
- Users regularly ask for "the history" and you have to assemble it from several places.
- Permissions are awkward: the natural access rule does not correspond to any single entity.
- Disputes are resolved by searching email rather than by reading a record.
When we moved the aggregate from the property to the tenancy, several problems dissolved at once. Access control became a membership question against a single entity. History became a query rather than a reconstruction. Financial records had an obvious home. And the maintenance request that had been ambiguously attached to a property now sat inside the relationship that would be billed for it.
The same error in other sectors
- Healthcare: teams model the appointment; the thing that persists is the episode of care.
- Education: teams model the lesson; the thing that persists is the learner's progression against objectives.
- Professional services: teams model the invoice; the thing that persists is the engagement.
- Financial services: teams model the account balance; the thing that persists is the ledger of transactions that produces it.
Getting this right is one of the highest-leverage hours in a project, and it is nearly free at the start. Changing it after launch means migrating data, rewriting permissions and re-teaching users. It is worth spending a morning on before anyone opens an editor.