Domain Modeling
A domain model is only useful if it is the real one — the language the business actually speaks and the rules they actually enforce. DevArch does not assume you start from a blank page. There are three ways into a model, two engines that build it, and a validation loop that turns guesses into facts the business has confirmed.
Three ways in
Most tools assume domain modeling is something you do up front, in conversation, before you build. That is one way in. It is not the only one — and for an existing system it is rarely the one that happens.
Emergent
You're building, and the boundaries start to show themselves. DevArch notices — the capability-sniffer and seam-detector surface the seams — and offers to model when there is something worth modeling.
Greenfield conversation
You're starting fresh and want to think in the domain first. /devarch:brainstorm and /devarch:domain-model run the knowledge-crunch — ubiquitous language, bounded contexts — before a line of code.
Existing codebase
You already have a system and want the model hiding inside it. /devarch:extract reads the repo and hands you a draft to react to.
Two engines, one notation
Every path lands in one of two engines, and both write the same domain notation. Downstream tooling cannot tell — and does not need to tell — how a given element was born.
Engine 1 — Knowledge-crunch
/devarch:domain-model
Facilitates the conversation that forges the ubiquitous language and discovers the bounded contexts. The model comes from the people who know the domain. This is where the emergent and greenfield paths land.
Engine 2 — Codebase extraction
/devarch:extract
Reads the code and emits the same notation, layered by how much it had to infer: the glossary it can observe, the structure it reads from module layout, and the behavior it guesses from patterns. Where the existing-codebase path lands.
The confidence gradient
Extraction is honest about what it knows. A codebase tells you some things directly and forces you to guess at others, so every extracted element carries a confidence level — and the difference is never hidden.
| Confidence | What it means |
|---|---|
| observed | Read directly from the code — the names are right there. The glossary. |
| inferred-structure | Read from module and package layout. A strong but fallible boundary signal. |
| proposed | Inferred intent — an aggregate or an invariant guessed from a pattern. A claim to check, never a fact. |
| confirmed | Validated by a domain expert through the primer loop. The only level a human can grant. |
Nothing reaches confirmed by extraction alone. The code can tell you what it does; only the business can tell you what it is supposed to do.
Validation: the SME primer loop
The only thing that turns a proposed element into a confirmed one is the person who actually knows the domain. /devarch:primer projects your notation out as plain-language questions — no jargon, one per element — that a business expert can answer in twenty minutes. An invariant becomes “is this always true? when has it been broken?” — the question that surfaces the exceptions only they know. Their reply comes back through /devarch:sources, and matching answers flip the elements to confirmed, each with a record of who validated what. A second primer asks only about what is still open.
See the command reference for /devarch:domain-model, /devarch:extract, /devarch:primer, and /devarch:sources — and when to reach for each.