jschoubben
0531d6fc38
011 opened asking what a graph deletes and found the graph already existed. The work became design, worked through twenty cases and one provider in full. Two decisions close it. 0044 — a module declares presence, instantiation and exclusion. Two kinds of edge because a game wanting a database is not a game wanting postgres to exist: one creates something per consumer, carries credentials back, can be revoked, and leaves the provider holding state. Names are concrete unless providers are genuinely substitutable — `terminal` passes, `database` fails, and the adapter is what creates an interface. Where there is no contract there is a tag, which describes and does not bind. Exclusion is a third relation and is not derivable. A node provides names too, which makes capability checking stop being a separate mechanism and makes the host's detection an input to resolution. Constraints, never placement. Scope decides which provider and the binding is written down and sticky, in a place that follows the scope. And there are three entities, not two — the assignment carries what belongs to neither end, which is what node-agnostic modules ran out of. 0045 — a context owns its store, exclusively. No shared writes and no read roles on another context's store, because reading couples you to its layout just as firmly and invisibly. The unit is the CONTEXT, not the process: a board showing the mesh's own data is the mesh showing its own data. Asking or subscribing is derived from ADR 0036 rather than chosen. And it is the first clear list of what the design removes: grant kinds, table ownership, cross-context migration ordering, and a class of permission modelling. 0017 is superseded rather than narrowed — its text unchanged, its status changed. Folders assert relationships where edges record them, and the domain module goes with it. Left explicitly undecided in both: what a resolver delegates rather than reimplements, how many instances a module should have, and what a provider hands back.
4.6 KiB
4.6 KiB
status, date, deciders, reconstructed, extends
| status | date | deciders | reconstructed | extends |
|---|---|---|---|---|
| accepted | 2026-08-26 | jochen | false | 0044-a-module-declares-presence-instantiation-and-exclusion.md |
45. A context owns its store, exclusively
Context
ADR 0044 settles what a module declares. This settles what a grant may be, and it is the half that removes things.
how-we-build §4 already says contexts integrate through the record, never through a shared
schema, and states the cost: several domains share one forty-five-table schema, which is why
work belonging to one context keeps having to be implemented in another.
That was written as a principle. Counted, it is thirteen foreign tables belonging to three separate contexts, living in the mesh's own registry database.
Considered options
- A schema per consumer inside a shared database. Namespaced, revocable by dropping the schema, with a cross-context join possible but deliberate. Rejected: it keeps the letter of §4 and leaves the temptation in place, and a boundary that is merely inconvenient to cross gets crossed.
- Read-only roles on another context's store. Rejected for the same reason and one worse: reading another context's tables couples you to its layout exactly as firmly as writing them, and the coupling is invisible until the owner changes a column.
- Exclusive ownership. Chosen.
Decision
A context is granted only what it exclusively owns.
No shared writes. No read-only role on another context's store. If you need what another context holds, you ask it or you subscribe to it.
The unit is the context, not the process. Everything inside a context — its service, its surface, its tools — reads its own store freely. A board showing the mesh's own nodes and modules is the mesh showing its own data, not a boundary crossing. What is forbidden is a different context reading it.
Asking or subscribing is derived, not chosen
ADR 0036 makes disconnection an ordinary situation. So:
- Anything that must keep working while disconnected cannot ask — there is nobody to ask. It keeps a local copy, which means subscribing.
- Anything where a stale answer is worse than none cannot subscribe. A display may lag; a decision about whether a grant is still valid may not.
Neither is a query against another store, whatever transport it travels over.
What this removes
The first clear list of what the design deletes rather than adds:
- Grant kinds. There is one: an exclusive resource. No schema grants, no read roles, no rules about who may see what inside a shared thing.
- The question of who owns which table, and the guessing at revocation time. Removing a consumer drops what it was granted, whole.
- Cross-context migration ordering. Two contexts migrating one database must be ordered against each other. Exclusive ownership means a context's migrations are ordered only against itself.
- A class of permission modelling a shared store would otherwise need.
Consequences
- Cross-context reporting is harder, and that is the point. Anything wanting to see across contexts consumes their events or calls their interfaces. That is §4's argument, and the cost it names is the one already paid.
- A single surface over several contexts still works — that is what a surface is. It reads interfaces, not stores. This holds while the contexts sit behind one interface; splitting a context into its own deployable costs that, and the composition would have nowhere to live that tier 3 permits. A real constraint on how far the control plane may be split.
- Three contexts must move out of the registry database, taking thirteen tables with them. Their dependency on the registry then shrinks to almost nothing — one of them needs a single table.
- The node appliers were already handled. ADR 0037 stopped the host querying the mesh database for tier reasons unrelated to this, and it removes most of the remaining direct readers as a side effect.
- What a consumer does about events missed while disconnected is not decided — replay from a point, ask once and resume, or rebuild. The question every projection has.
References
how-we-build.md§4 — the rule this makes enforceable.- Research 011 — the count, the worked provider, and the dashboard case.
- ADR 0036 — why asking or subscribing is derived.