011: one interface, many contexts — and the constraint that hides in it

The objection is right: if every context runs its own service with its own interface, the board is coupled to N interfaces instead of N schemas, something has to compose them, and composition is logic — which tier 3 says a surface does not hold. That moves the problem up a layer rather than solving it. The skeleton already answers it, and the previous entry talked past it. `work` and `knowledge` are not separate services; they are contexts INSIDE the control plane, alongside the record, inventory and delivery — and `api` is listed there as the one interface every surface speaks to. So the board speaks to one interface. Behind it the contexts stay separate, integrating through the record, but they are one tier, one repository, one deployable — and coupling within a tier is not what the tier rule forbids. The problem does move up a layer, and the layer it moves to already exists and has this as its job. The caveat is load-bearing and now recorded as an open question: this holds only while the contexts are not separate deployables. The moment one becomes its own service with its own interface, the board is back to N clients, something must compose them, and the composition has nowhere to live that tier 3 permits. That is a real constraint on how far the control plane may be split, and it is worth knowing before splitting rather than after.
2026-08-26 23:29:56 +02:00
parent a4a25ca7e3
commit a4ab3e15c2
2 changed files with 26 additions and 2 deletions
@@ -240,8 +240,31 @@ a context's interface, that interface is inadequate — discovered in the one pl
 cheap to notice, rather than the first time something else needs the same data and quietly
 reaches for the store instead.

-If composing many calls turns out too slow, the answer is a projection the board owns and keeps
-current from events — not access to somebody else's tables.
+**But "the board calls each context's interface" is not quite it either**, and the objection is
+right: if every context runs its own service with its own interface, the board is coupled to N
+of them instead of N schemas, something has to compose them, and composition is logic — which
+tier 3 says a surface does not hold. That moves the problem up a layer rather than solving it.
+
+**The skeleton already answers this and the argument above talked past it.** `work` and
+`knowledge` are not separate services; they are **contexts inside the control plane**, alongside
+the record, inventory, delivery and the rest — and `api` is listed there as *the one interface
+every surface speaks to*.
+
+So the board speaks to **one** interface. Behind it the contexts stay separate: separate stores,
+integrating through the record. But they are one tier, one repository, one deployable, and
+coupling *within* a tier is not what the tier rule forbids.
+
+Which resolves the objection rather than deflecting it: the problem does move up a layer, and
+the layer it moves to already exists and has this as its job.
+
+**The caveat is load-bearing.** This holds only while the contexts are not separate deployables.
+The moment one becomes its own service with its own interface, the board is back to N clients,
+something must compose them, and the composition has nowhere to live that tier 3 permits. That
+is a real constraint on how far the control plane may be split, and it is worth knowing now
+rather than discovering it by splitting.
+
+If composing even one interface turns out too slow, the answer is a projection the board owns
+and keeps current from events — not access to somebody else's tables.

 ### Checked against the real consumers