Domains
Perhaps the biggest choice in this design is where to draw the lines between parts of the system. Fifteen families of domain model. One family is really five case models, one per program, which makes nineteen models in all.
The problem of a single model
Programmes like this usually start by building one model of a case that every program can share. That is how MIS began, and how ICM began. It looks like the responsible choice: less duplication, one place to change things, one way of working across the ministry.
What happens next is well documented. A child protection investigation and a child care subsidy renewal have almost nothing in common beyond involving a person. Make them share a lifecycle and every change to one has to be negotiated with everyone else. Multiply that over dozens of programs and nobody can change the model at all. So teams bolt on sub-entities, extend them, and add more ways to integrate. The system turns into a plate of spaghetti. You cannot change anything in one place, and any failure reaches everywhere. This is not hypothetical. ICM merged its final two phases and cut child protection scope for exactly this reason.
This design takes the difference seriously. Five program families get five case models. The plumbing is written more than once, and that is cheaper than the alternative.
What the parts are
Identity, evidence and decisions
One per program family
Money
Delivery
Information governance
Twelve families were drawn when the architecture was first issued, which made sixteen models. Three more were added later, because nothing in the map modelled how the ministry holds what it knows: Consent & Disclosure, Investigation & Loss Management, and Channel Entitlement & Service Restriction. The family name “Case & Service Delivery” never owns anything. The owner is always one of the five case models.
Six rules keep the lines in place
A boundary that lives only in a diagram will not survive delivery pressure. These six are written so a reviewer can point at something and say whether it complies.
Each part can be released on its own
It has its own storage and its own message topics. If two parts always ship together, they are one part wearing two names.
No part reads another part's database
No shared tables. No joins across schemas. Not for a report, and not in a test environment. This rule erodes first, and takes the longest to notice.
There are exactly two ways to talk
A published interface for reads, and published events for notices. There is no third way, and adding one is not a shortcut.
Copies are owned by whoever holds them
A part that needs another's data keeps its own copy, built from that part's events and shaped the way it needs. When the source corrects something, the copy has to follow.
Reference data has one master
Rate tables, program codes, value lists and reason codes are each kept in one place and published as events. Nobody maintains a second copy by hand. They change when policy changes, not when the software does.
Every copy is stamped
When a part copies evidence, it records where the copy came from: which part, which piece of evidence, which version, when the source learned it, and when the copy was taken. That is what makes rule four checkable. A correction can find every copy by looking it up, not by asking every team.
The thin identity model
Participant Identity stays deliberately small. It holds identifiers, enough detail to tell two people apart, and whether anyone has proven the identity. No addresses, no income, no relationships.
This part is the most likely to drift, because every new requirement brings a reason to add one more field to the person record. Once that starts, the shared model is back, in the one place the design most needs to stay thin.
Merge and split go in on day one rather than later. The audit of the previous system found duplicate records at scale, and called its search ineffective and exact-match only. Adding merge afterwards to a system that assumed one person equals one row is close to impossible. By then every payment instruction and every stored decision has keyed itself to an identifier the design promised would hold still.
Published events and the boundary test
Participant Identity publishes PersonRegistered, IdentityMerged, IdentitySplit, IdentifierAdded and IdentifierInvalidated. Every other context keeps its own projection (Payee,
Applicant, Caregiver, Reporter, Appellant, Debtor), keyed by participant identifier.
Evidence & Verification publishes EvidenceRecorded, EvidenceActivated, EvidenceSuperseded, EvidenceVerified, EvidenceInvalidated and EvidenceCorrectionRecorded.
Parts that are not domain models
Some pieces are shared infrastructure rather than parts of the business. Platform teams own them and everyone uses them. The difference matters. A platform part that starts holding program state has quietly become a twentieth domain model, and nobody chartered it.
The platform parts are the published interface (the Open Host Service), the translation layer over the old system (the Legacy Anti-Corruption Layer), Secure Data Exchange for sharing with other organisations, Rules Authoring & Release, the Component Library, the Analytical Platform, and Correlation & Migration State, which keeps track of which old record matches which new one. Three more services hold no program state of their own: severing, routing a correction to the parts that own the fact, and carrying out retention and disposal.
Two of them are worth naming, because their charters point in opposite directions on purpose. The published interface is permanent: it is the contract built to outlive whatever implements it. The translation layer over the existing Siebel system is temporary, and the team that builds it answers for winding itself up.
A team accountable for a thing will grow and protect it. A team measured on its own dissolution will not.