Ordering: the depended-upon goes first

Parent: structure · Kin: domain-facade-and-ddd-layout · backend-domain-modules

A rollout rule, and a rule about who decides the rollout.

The depended-upon module goes first. Where nothing depends on anything, take them in the order they were named, and start.

Why it is written down

A migration with N modules has N! possible orders and, usually, one real constraint: some modules are read by others. Once that constraint is honoured, the remaining freedom is not a decision — it is a coin flip dressed as one. And a coin flip handed back as a question costs a full round trip, invites an answer that carries no information, and stalls work that could have been done while asking.

So the rule has two halves, and the second half is the load-bearing one: stop asking which one next. "Which should I do first?" is a real question exactly when a dependency exists — and then the answer is mechanical, so it does not need asking either.

How it plays out

• Whatever every other module reads goes first: the shared vocabulary, the identity types, the error surface. Migrating a consumer before its dependency means the consumer imports the old shape and gets migrated twice.
• Where two modules genuinely do not touch, the order is the order they came up in the plan. That is not laziness — it is refusing to spend judgement where no judgement is available.
• The plan states the order before the first edit, so a session that resumes mid-way reads the order rather than re-deriving it. A re-derived order is where a second, different order gets invented.

The general shape

This is one instance of a wider stance: derive rather than ask. Most questions that feel like they need the owner have already been answered by a principle already written down — and the ones that genuinely need a person are usually about authority (what may this be allowed to do), not about sequence. Order is derivable; permission is not.