How to model a use case as a path through the architecture
Express a use case against the architecture rather than in a document: an ordered path across the components that have to deliver it, which makes it visible which components are load-bearing for the requirement and which steps have nothing serving them.
When this is useful
- A requirement exists in a document and nobody can say which components deliver it.
- A component is proposed for retirement and you need to know which capabilities run through it.
- A design review needs a concrete question to assess the architecture against rather than a general impression.
Before you start
- A diagram with the components on it. A path is drawn across components, so they have to be modelled first.
- The use case in one sentence, in business terms. If it takes a paragraph, it is probably two use cases.
Step 1: Open the patterns panel
Use cases are modelled from the panel at the bottom of the editor, on the Patterns tab. The tab appears when the capability is available to you; where it is not enabled the editor falls back to the entity view.
Step 2: Describe the use case, then lay out its path
Name the use case in the language the business uses, then mark the ordered path across the components that serve it — the entry point, each component the request passes through, and where it ends.
A path is coarser than a sequence diagram on purpose. It answers "which components does this capability depend on", not "what is the exact message ordering" — that is what a sequence is for.
Step 3: Read the gaps
Once paths are modelled, two kinds of gap become visible: a step with no component to serve it, and a component that no path passes through. Both are worth knowing before anybody builds anything.
The first is a hole in the architecture. The second is either a component nobody needs, or — more often — a use case nobody has modelled yet.
Step 4: Use the paths downstream
Paths describe realistic flows, which is what makes a workload simulation meaningful rather than synthetic. They also give a reviewer something specific to assess: run the model against the paths and validate it rather than judging the picture.
Simulate ▸ Workload ProfileSimulate ▸ Simulation PanelData ▸ Validate Model
What happens next
The requirement is now structural. A change to a component can be assessed against the use cases that run through it, which is a far more concrete question than whether the change "affects the architecture".
Impact analysis and the simulation both become more useful, because both now know which flows actually matter.
Example
A checkout use case modelled as a path: web front end, orders API, inventory, payments, fulfilment queue. Modelling it revealed a reporting service that no path touched — which turned out to be a capability nobody had written down rather than a component nobody needed.
Tips
- Model the three or four use cases that carry the business first. Complete coverage of every edge case is a much later concern and rarely changes a decision.
- When a path and a sequence diagram disagree, the sequence is usually right about ordering and the path is usually right about scope. They are answering different questions.
- A component on no path is a question, not a finding. Ask it before removing anything.
Limitations
- Use case modelling is a separately enabled capability; where it is not enabled the Patterns tab does not appear.
- A path records which components serve a capability and in what order. It does not model conditional branches — a use case with genuinely different paths is modelled as more than one.