Files
hq/01-RESEARCH/005-domain-grouping/00-overview.md
T
jschoubben 7a20358113 research 006: the code skeleton, and where postgres lands
A tier test as a decision procedure — five ordered questions, first match
wins — so placement is answerable rather than argued.

Postgres was the test case and the naive answer is wrong. Not twice, once:
the control plane cannot exist without a relational store, so it is tier 1
and lives in hal-substrate/store/postgres. What differs between the mesh's
own database and a project's is not the module but how that instance is
brought up — pinned bundle applied by the host, versus the ordinary
delivery and provisioning path. Tier is a property of the module; the
bundle is a property of the mesh's own instance. The naive answer would
also have made substrate reach up into the catalogue, which the dependency
rule forbids.

Working the test across the catalogue surfaces a third fate that neither
of research 005's options covers, and it is the most common one: absorbed
into the host, ceasing to be a module at all. That explains 005's one
positive measurement rather than confirming it — the reachability cluster
is not four modules that should be one domain module, it is four facets of
one thing the host should own, expressed as modules because a module was
the only unit available. Under this skeleton the overlay and firewall
modules stop existing. It also partly answers the silent fifty: several
are host concerns, so silence was the right signal and grouping was the
wrong inference.

Flags rather than settles: the identity provider is a genuine boundary
case (four substrate services or five), and absorbing six concerns into a
binary whose argument is that it has no dependencies is the skeleton's
biggest unproven claim.
2026-08-23 20:40:32 +02:00

3.2 KiB

status, initiated, touches, became
status initiated touches became
active 2026-08-23
02-DECISIONS/0017-modules-outside-the-core-are-grouped-by-domain.md
03-DESIGN/00-as-is/10-module-catalogue.md
03-DESIGN/00-as-is/02-modules-and-manifests.md

005 — Which domains the catalogue groups into

ADR 0017 settles that modules outside the platform core are grouped by domain rather than by single function, and deliberately does not settle the list. This effort settles the list — and, first, tests whether the premise survives measurement.

What is being investigated

Eighty-nine modules sit outside the platform core. The question is which of them belong together, and the method is evidence rather than intuition: which modules actually change together, measured across the full history of the code repository.

Why

The argument in ADR 0017 is that the catalogue's shape records what was installed rather than what anything is for — that four modules constituting "how a node is reachable" have no relationship the mesh can see, so a change to connectivity is made four times.

That argument is testable. If those modules genuinely change together, the grouping is justified by more than tidiness. If they do not, the premise needs revising before a list is drawn from it.

What it touches

The catalogue's shape, the manifest, and — for one candidate grouping — the provisioning reference itself, since a requirement names a provider module. Grouping providers would change what a consumer names.

Status

Measurement is done and is in analysis.md. It partly contradicts the premise, in a way that narrows the effort usefully:

  • Non-platform modules overwhelmingly change alone — 10% of commits touch more than one, and 50 of 89 never co-change with anything.
  • Two clusters do exist. One of them, reachability, holds up as a domain.
  • The other, the provisioned infrastructure providers, co-changes for a reason that argues against grouping rather than for it.

The remaining work is the list itself, for the modules where grouping is justified, plus the open questions below.

Open questions

Question Why it is open
Whether provider modules group at all, and if so what a consumer's requirement names instead of a module. The provisioning reference is load-bearing; getting it wrong is expensive. Opinion and evidence in the analysis; not yet decided.
Whether applications group into domains now and leave the monorepo later as a unit, or leave first. Decided in principle — group first, then split — but the migration order has real cost either way.
What to do with the ~50 modules that co-change with nothing. The evidence gives no grouping signal for them at all. That may mean they are correctly sized already.
Whether "group or leave" is even the right pair of options. Research 006 finds a third fate — absorbed into the node host, ceasing to be a module at all — and argues it is the correct answer for the reachability cluster this effort measured. If so, the cluster this effort found is evidence for absorption rather than for grouping.