Systems
Most platforms do not fail at the interface. They fail because the transaction was never modelled — so every new requirement adds a branch, and the branches eventually contradict each other.
You are probably reading this because:
A feature that should take days takes a sprint, and nobody can say why.
The same order can be in two states at once, depending on which screen you ask.
Reporting disagrees with the database, and both are defended by someone senior.
Two products were merged and now share a schema neither of them fits.
- 01
Transaction and state modelling
We write down the states an order, an account or a booking can legally occupy, and the transitions between them. Most of the defects in a mature platform live in the transitions nobody named.
- 02
Domain invariants before features
What must remain true regardless of release — balances that reconcile, bookings that cannot overlap, prices that cannot be negative. These become constraints in the system rather than conventions in a document.
- 03
Consistency and failure isolation
Where the system must be strongly consistent and where it can settle later, which failures may propagate and which must be contained, and what the platform is allowed to do when a dependency is down.
- 04
Unifying several products on one core
Companies that ship three products usually maintain three half-domains. We define the shared core and the seams, so the products stay separate where they differ and stop diverging where they do not.
- 01
A state and transaction model of the domain, written so a non-engineer can argue with it
- 02
An architecture definition: boundaries, contracts, consistency and failure behaviour
- 03
A migration path from the system you have to the one described, in shippable stages
- 04
The invariants, expressed as constraints and tests rather than as documentation
Invariant
The domain model is the product. Everything above it is an interface to it.
- Do you rewrite the platform?
- Rarely, and never as an opening move. A rewrite is the most expensive way to discover that the original model was the problem. We model first, correct the model in place where that is possible, and reserve replacement for the components that cannot be corrected.
- How long does an architecture engagement take?
- The definition itself is usually four to eight weeks depending on the number of products involved. Implementation runs longer and is staged so that value lands before the last stage.
- Do you work with our existing engineering team?
- That is the normal case. We operate close to the CTO and the core team; the architecture has to be something they can carry after we leave, or it was theatre.