The final project of K4 has one goal: the Kladde serves several offices. So far exactly one invented IT office works in it. At the end of this module, several invented offices work in it, each sees only its own data, the Kladde runs in Azure the way your ADR on the tenancy model from lesson 4.7.6 laid down, and you can prove each of these statements.
The module has no checkpoint task of its own. The final project brings the whole level together: a person from your circle checks your work in the review (4.9.6), and you check it yourself with a checklist in the architecture review (4.9.7). Until then you go through these steps:
| Lesson | What comes out of it |
|---|---|
| 4.9.1 Planning | Issues with acceptance criteria, milestones, a proof of concept for the biggest risk |
| 4.9.2 Creating and dissolving tenants | Offices in the Tenants context, the office of every request from the token, suspending and removing |
| 4.9.3 Proving isolation | a test series that attacks every read and write point with a foreign office |
| 4.9.4 Delivering and operating | the Kladde multi-tenant in Azure, rollout in rings, a disaster drill for one office, cost per office |
| 4.9.5 Architecture documentation | docs/ complete and current with the code |
| 4.9.6 Architecture review | a review of another person's work and answers to the review of your own |
| 4.9.7 Architecture review with a checklist | demo, code reading and questions across K4, checked against a checklist |
In this lesson you plan. That sounds like the easiest part, but it is the one where projects fail most often: not because of hard code, but because the hardest problem only shows up in the last week.
Where the Kladde stands now
Before you plan what is still missing, write down what is already there. In K4, every module so far has added something that prepared multi-tenancy:
| Module | What is already there |
|---|---|
| 4.1 | quality goals with “several offices in one Kladde”, ADRs, the C4 context and containers, the cost calculation with the figure “cost per office” |
| 4.2 | the Tenants context (Tenants) with office, staff and roles, data ownership per context |
| 4.3 | TenantId in the shared kernel, in every aggregate and every storage key; ICurrentUser reads the office from the token; the architecture test |
| 4.4 | the event store with the column TenantId and the unique key on office, stream and version; read models with TenantId |
| 4.5 | grains with the key {tenant}/{id}, a cluster with two silos in Container Apps |
| 4.6 | outbox, inbox, the process “quote accepted”, the anti-corruption layer for TED |
| 4.8 | threat model, redaction in logs, erasure and access for contacts, the permissions table |
| 4.7 | network and governance in Bicep, sign-in from several Entra directories, a disaster drill, the ADR on the tenancy model |
| 4.10 to 4.14 | the ADRs on code architecture and data architecture, depending on your path a service of its own for the tenders (4.12), the estimate from 4.14.2 |
What is missing is the part that turns “every key carries an office” into a real multi-office system:
- So far the office is the Entra directory. Since 4.3.5,
ICurrentUserreads the directory IDtidfrom the token and takes it directly as theTenantId. Anyone who may sign in from any directory would thereby have an office of their own. What is missing is a registry of offices that says which directories belong to which office and whether the office may work right now. - Nobody has proven that the tenant ID works everywhere. It is in the keys. Whether every query, every read model, every search and every export uses it as well has not yet been checked by a test for all the places.
- There is no operation per office. Suspending an office, removing it, restoring it from a backup, measuring its cost: none of that has ever happened.
If you estimated the effort of multi-tenancy as a range in lesson 4.14.2, put that estimate next to the plan now. At the end of the module you compare it with what it really cost.