Architecture and Design
TOGAF, DDD, target-state, strangler-fig, C4, ADRs — not a glossary, a sequence.
Solution Architecture · Enterprise Architecture (TOGAF 10) · Target-State & Transition Architecture · Microservices · Event-Driven Architecture · Domain-Driven Design · API-Led Integration · Strangler-Fig Migration · C4 Modelling · HLD / LLD · Architecture Decision Records
Eleven terms, comma-separated, in no particular order. It reads as a keyword list — and interviewers read it that way too, which is why the follow-up question is usually some variant of "pick one and tell me what you actually did with it."
But they aren't eleven independent skills. On a real modernisation they happen in a specific order, each one answering a question the previous one raised. This post walks that order, and says where each concept earns its keep — and where it doesn't.
The running example throughout: you have been handed a legacy monolith and asked to modernise it. That is the engagement most of these words were invented for.
1 · Where you sit — enterprise vs solution architecture
The first question is not technical. It is what am I allowed to decide?
Enterprise architecture is the organisation-wide view: the capability map, the technology standards, the principles, the roadmap across many programmes. Solution architecture is one solution inside that frame. If you are the solution architect, the EA function is your constraint set and often your approval gate.
Getting this boundary wrong is the most common early mistake. Architects who ignore the EA context design something elegant that gets rejected at a design authority for using a database the organisation has committed to retiring. Architects who over-defer produce a design that satisfies every standard and solves nothing.
What TOGAF is actually for
TOGAF 10 gets sneered at, usually by people who have only met it as a certification. Its real value is not the ADM phases — most organisations that "do TOGAF" by running every phase produce enormous documents nobody reads.
Its value is vocabulary and artefacts. It gives you agreed words for baseline, target, and transition architecture, and a standard set of deliverables that a governance body already knows how to review. When you present a target-state architecture and a set of transition architectures, a TOGAF-literate design authority knows exactly what it is looking at and what it is being asked to approve.
That is the honest pitch: TOGAF is a shared language for getting decisions made in large organisations. Use the parts that buy you that and skip the rest.
Worth saying in an interview
"I use TOGAF for the artefact vocabulary and the governance touchpoints, not as a process to follow end to end. Running the full ADM on a single solution is usually ceremony." This lands well because it signals you have used it rather than passed an exam on it.
2 · Finding the seams — domain-driven design
You now know your scope. The next question is where does this monolith naturally come apart?
This is where domain-driven design does its real work — and it is almost always applied too late. DDD is not a coding style. Its contribution at this stage is the bounded context: a boundary inside which a term means exactly one thing.
The classic example is worth using because it is true everywhere. "Customer" in a billing context is an account with a payment method and a credit limit. "Customer" in a support context is a person with a contact history and a sentiment score. Same word, different model, different lifecycle, different team. That is two bounded contexts, and the seam between them is where a service boundary belongs.
Why this matters more than any technology choice: if you draw service boundaries from the existing database schema or the current team structure instead of from the domain, you get a distributed monolith — services that cannot be deployed independently because every change touches three of them. You have taken on all the operational cost of microservices and none of the benefit. This is the single most common failure mode in modernisation programmes, and it is decided at this step, months before anyone writes a service.
The practical technique
Run event storming with the people who actually do the work — not their managers. You put domain events on a wall in time order, then cluster them. The clusters are your candidate contexts. It takes a day or two and it is worth more than a month of reading the existing code.
Then draw a context map showing how the contexts relate: which is upstream, which is downstream, where you need an anti-corruption layer to stop a legacy model leaking into a clean one.
3 · Where you are going — target-state architecture
Now you can describe the destination.
A target-state architecture describes the estate as it should be once the work is complete: the contexts as services, the data stores, the integration patterns, the runtime platform, the non-functional characteristics it must hit.
Two rules I would defend in any review:
The target state must be falsifiable. "Cloud-native, scalable, event-driven" is not a target state, it is an aspiration. A target state names the services, the data ownership, and the specific non-functionals — this service owns order data, exposes it over an API-led contract, and must sustain 400 requests per second at p95 under 200ms. If nobody could ever tell you that you had failed to reach it, you have not described it.
The target state is allowed to be wrong. It is a hypothesis about a future that is eighteen months away. Write it as a document with a version number and a review date, not a monument.
4 · How you get there — transition architectures
This is the step most architects skip, and it is why modernisations stall.
A transition architecture is an intermediate state that is itself deployable, operable and valuable. Not a milestone on a Gantt chart — a real architecture you could run the business on if the programme were cancelled tomorrow.
The test is blunt: if funding stopped at the end of this transition, would the organisation be better off than before it started? If the answer is no, it is not a transition architecture, it is a partially finished migration. And funding does stop. Priorities change, sponsors move, budgets get cut. A modernisation composed of three well-chosen transition states survives that; one composed of a single eighteen-month leap to the target state does not.
In practice each transition typically moves one or two bounded contexts out, leaves the rest in the monolith, and routes traffic accordingly. The legacy system keeps running throughout.
The interview version
When someone asks how you approach a migration, the answer that separates you is not "strangler-fig" — everyone says that. It is "I define transition architectures such that each one is independently valuable, because programmes get cancelled and I want every stage to have left the estate better than it found it."
5 · What shape it takes — microservices, events, and API-led integration
Only now does the technology shape get decided, and this ordering is deliberate: the shape follows the seams, not the other way round.
Microservices are an organisational decision first
Conway's law is not a curiosity, it is a design constraint. Microservices buy you independent deployability — and independent deployability is only worth its cost if you have independent teams who need to ship without coordinating.
Three teams and a monolith they can all release weekly? Microservices will make you slower. Twelve teams blocked behind a shared release train? Now the cost is worth paying.
Be honest about that cost: distributed tracing, service discovery, contract versioning, eventual consistency, a deployment pipeline per service, and a much harder debugging story. A modular monolith with clean bounded contexts is frequently the better answer, and saying so in an interview signals judgement rather than fashion.
Event-driven architecture buys decoupling and charges you in debuggability
Publishing an event instead of calling an API removes the temporal coupling between producer and consumer. The producer does not know or care who listens. That is genuinely powerful — it is what lets you add a new consumer without touching the producer.
What it costs you is linear reasoning. With a synchronous call you can read the code and follow the request. With events you cannot; you have to reconstruct the flow from a trace. Choose it where the decoupling is worth that, and instrument accordingly from day one — correlation IDs threaded through every message, not added after the first incident.
Also decide explicitly between event notification (thin message, consumer calls back for detail) and event-carried state transfer (fat message, consumer needs nothing else). The second removes a runtime dependency and costs you payload size and staleness. Architects who have not thought about this distinction get caught out by it.
API-led integration is about contracts, not about REST
API-led means the boundary between contexts is an explicit, versioned contract rather than a shared database or a direct table read. That is the whole idea. Whether it is REST, gRPC or GraphQL is a downstream detail.
The discipline that makes it work is contract ownership: the service owning the data owns the contract, consumers code against the contract, and breaking changes go through versioning rather than a coordinated release. The moment a consumer reads the producer's database directly, you no longer have an architecture, you have a shared mutable global.
6 · Actually moving — strangler-fig migration
You know the seams, the destination, the route and the shape. Now you move — without a big-bang cutover, because big-bang cutovers of business-critical systems fail at a rate that should end the conversation.
The strangler-fig pattern puts a facade in front of the legacy system and moves functionality behind it one piece at a time. Traffic for migrated capability routes to the new service; everything else falls through to the monolith. Both run in parallel, indefinitely if need be.
The facade is easy. The data is not.
Every article on strangler-fig spends its time on routing. Routing is a gateway rule. The difficulty is that the monolith's database is one schema with foreign keys across every context, and your new service needs to own its data.
The options, none of them free:
| Approach | How it works | Cost |
|---|---|---|
| Synchronise both ways | New service owns its store; changes replicate back to the legacy schema | Two sources of truth during transition; conflict handling |
| Legacy stays authoritative | New service reads from legacy, writes through it | Simple, but the new service does not really own its data yet |
| Hard cut per context | Migrate the data, repoint everything, delete the old tables | Cleanest end state, needs a real outage window per context |
Pick per context rather than globally, and write down which one you picked and why — which is the next section.
Have a stopping rule
Strangler-fig migrations die half-finished more often than they fail outright. A facade, three new services, and a monolith that still owns 70% of the functionality is the worst of both worlds, and it is a stable equilibrium because the remaining pieces are always the hardest.
Decide up front what "done" means and what you will do with the remnant. Sometimes the honest answer is that the last 20% stays in the legacy system permanently, wrapped and left alone. That is a legitimate target state. An unplanned version of it is not.
7 · Communicating it — C4 and the HLD/LLD pair
An architecture that cannot be explained does not get approved, and an architecture that is explained differently to each audience does not get built.
C4 works because it has exactly four zoom levels
| Level | Question it answers | Who reads it |
|---|---|---|
| 1 · Context | What is this system and who uses it? | Everyone, including non-technical stakeholders |
| 2 · Container | What are the deployable units and how do they talk? | Architects, senior engineers, ops |
| 3 · Component | What is inside one container? | The team building that container |
| 4 · Code | What are the classes? | Almost nobody — generate it if you need it |
The discipline that makes C4 useful is the zoom relationship: each diagram elaborates exactly one box from the level above. That is what stops the sprawling any-shape-any-arrow diagrams that most organisations call architecture. If you take one thing from C4, take that constraint.
In practice you will draw levels 1 and 2 constantly, level 3 for the complicated containers, and level 4 essentially never.
HLD and LLD, and which one people actually read
The high-level design is the solution-wide document: context, containers, integration patterns, data ownership, non-functional requirements, security model, and the decisions that shaped it. It is what goes to a design authority.
The low-level design is per-component: schemas, interface definitions, sequence flows, error handling, retry semantics.
Being realistic about their lifespan changes how you write them. An HLD is read carefully once, at approval, and then skimmed. An LLD is read by the team building the thing and then goes stale within a quarter. Neither is where your reasoning survives — which is the last piece.
8 · Recording why — architecture decision records
The most valuable document in the set is also the smallest.
An architecture decision record is a short file, in the repository, capturing one decision: the context, the options, what was chosen, and what it costs. One decision per record, numbered, immutable. When a decision is reversed you do not edit the old record — you write a new one that supersedes it, and the history stays visible.
# ADR-014 · Event-carried state transfer for order status
**Status:** Accepted · 2026-03-11 · supersedes ADR-009
## Context
Fulfilment, billing and notifications all need order status. Today each
calls the Orders API on every state change — roughly 40 calls/sec at peak,
and an Orders outage takes all three down with it.
## Decision
Orders publishes a fat OrderStatusChanged event carrying the fields
consumers need. Consumers maintain their own read models.
## Consequences
- Orders is no longer on the critical path for those three services
- Consumers tolerate staleness of up to ~2s
- Payload is larger, and adding a field consumers need is a contract change
- We now have four copies of order status and must accept that
## Alternatives considered
- **Thin event + callback** — keeps payload small but leaves the runtime
dependency on Orders, which was the problem we set out to solve
- **Shared read replica** — rejected; reintroduces schema coupling
The section that earns its place is "alternatives considered." Eighteen months later, someone will propose the thing you already rejected. Without the record they will re-litigate it from scratch, usually badly, and possibly do it. With the record the conversation takes five minutes.
ADRs also do something no other artefact does: they make an architect's reasoning reviewable. A colleague can disagree with a decision and see exactly which assumption they disagree with.
A tell worth knowing
If you are interviewing an architect and want one question that separates depth from vocabulary, ask them to describe a decision they got wrong and how they found out. The people who keep ADRs answer it immediately, because they wrote the superseding record themselves.
What this sequence is really for
The eleven terms are not a toolkit you pick from. They are a chain in which each link answers a question the previous one opened:
EA / TOGAF — what am I allowed to decide, and who approves it?
Solution architecture — what is my scope?
DDD — where does this system come apart?
Target-state — what does good look like, specifically?
Transition architectures — what is the route, and is each step worth shipping alone?
Microservices / EDA / API-led — what shape, and is the cost justified?
Strangler-fig — how do we move without a big bang?
C4 / HLD / LLD — how do we explain it to each audience?
ADRs — how does the reasoning survive us?
An interviewer asking about any one of these is usually probing whether you know its neighbours. Someone who can explain why bounded contexts must precede service boundaries, or why a transition architecture has to be independently valuable, is demonstrating that they have run the sequence — not that they have read the list.
And if you only adopt one thing from all eleven: write ADRs. They are the cheapest artefact here and the only one that is still being read in three years.