Software engineering invests enormous effort in measuring quality.
We measure test coverage, deployment frequency, pipeline stability, mean time to recovery, cyclomatic complexity, static analysis scores, sprint velocity, and more. Dashboards are green. Pipelines are healthy. Releases are frequent.
And yet, many systems become expensive to change, difficult to reason about, and fragile under evolving business requirements.
This contradiction—excellent technical health paired with declining business adaptability—is not accidental.
The most important quality attribute of business software is business fit—and it is almost entirely ignored. Not because teams are negligent, but because business fit cannot be measured, and most software systems provide no way to even assess it.
The Missing Quality Dimension: Business Fit
Business software exists to represent, enforce, and evolve business rules. Its primary responsibility is not technical excellence, but semantic correctness over time—what we can call business fit.
A system with strong business fit doesn't just mirror today's requirements; it makes the domain explicit and composable. New functionality slots in with minimal restructuring. Unexpected capabilities often emerge naturally from the model's structure itself—not through over-engineering, but because the right concepts are in the right places.
Consider a compliance system handling money transfers. Record the justification as free text, and you have a fragile string to search. Tie the transfer to a structured rental agreement with defined amounts and terms, and suddenly you gain automatic reconciliation, variance detection, and richer audit trails—features neither developers nor business stakeholders may have explicitly requested, yet they flow directly from the model.
Business fit reveals itself in questions like:
Does the system accurately represent the business domain?
Are business rules enforced structurally, or procedurally?
When the business changes or expands, does the system adapt locally with little friction, or require global refactoring?
Does the model reveal constraints and possibilities, or obscure them?
These questions govern long-term cost, risk, maintainability—and the system's capacity for sustained evolution and serendipitous power. Yet these questions—and the upside they unlock—are almost entirely absent from quality discussions.
Why?
Because business fit is not measurable.
Why Business Fit Cannot Be Measured
Business fit resists quantification for structural reasons:
It is semantic, not technical
It is contextual, not absolute
It evolves as the business evolves
It requires understanding, not observation
There is no metric for:
“Does this concept belong here?”
“Is this rule intrinsic or incidental?”
“Is this model still aligned with reality?”
Any attempt to measure business fit collapses into proxies. And proxies inevitably drift.
So teams measure what can be measured instead.
Metrics as a Substitute, Not a Solution
In the absence of a way to assess business fit, software development culture gravitates toward technical metrics:
Test coverage
Build health
Velocity
Static analysis
Reliability indicators
These metrics are not wrong. They are simply orthogonal.
They answer: “Is the system functioning?”
They do not answer: “Is the system correct in its representation of the business?”
Metrics fill the vacuum left by the absence of a semantic quality instrument. They do not replace it.
The Role of the Domain Model
The problem is that metrics measure the use of the language—but metrics do not test whether the story told is correct.
A rich domain model, by contrast, is a representation of the business domain—the story—itself.
Now that model does not directly measure the fit, but it does something more important: It makes business fit assessable.
A domain model:
Makes business concepts explicit
Centralizes rules and invariants
Attaches behavior to meaning
Provides a stable object of inspection
This enables something no metric ever can: business validation.
A business expert can look at a domain model and say:
“This is wrong”
“This is missing”
“This does not reflect reality”
That is not subjectivity. That is validation against the source of truth.
Without a domain model, that conversation is impossible.
Localization: Knowing What Happens Where
A strong domain model provides grounded context. It tells you:
What exists
Where logic lives
Which rules apply to which concepts
This localization dramatically reduces change cost. When a rule changes, you know where it must change.
In systems where logic lives in services, pipelines, or streams:
Meaning is scattered
Rules are duplicated
Ownership is unclear
Change becomes archaeology.
A domain model is not overhead—it is orientation infrastructure.
The Map Analogy
A domain model is to software what a map is to a city.
In a small village, you can navigate without one. You can keep everything in your head.
As the city grows, orientation becomes mandatory.
Without a model, developers navigate large systems the way a tourist navigates an unfamiliar city without a map:
By trial and error
By memory of past paths
By asking the same questions repeatedly
You can move. You can deliver. But you are never oriented.
The Ferrari Problem
What happens if business fit is never assessed?
Nothing fails immediately.
The system runs. Tests pass. Releases happen. Metrics look healthy.
This is why the problem persists.
It is like plowing a field with a Ferrari F40:
It moves
It is powerful
It looks impressive
But it is:
Grossly mismatched to the task
Fragile under load
Expensive to maintain
Poor at actual plowing
The work gets done—at extraordinary cost.
The Invisible Tractor
Here is the deeper problem: there is no obvious comparison.
Most teams have never seen a system with strong business fit evolve over time.
If no one has ever seen a tractor plow a field, the Ferrari looks like a reasonable choice.
A well-fit, model-driven system:
Changes quietly
Requires fewer people
Produces less drama
Does not generate hero stories
It does not look impressive—unless you care about farming.
In the absence of contrast, inefficiency becomes indistinguishable from necessity.
The Real Conclusion
Most software systems do not measure business fit. More importantly: they cannot.
Without a rich domain model, there is no tangible artifact against which business correctness can be evaluated. Quality becomes inferred from proxies. Correctness becomes assumed.
The uncomfortable truth is this:
The most important quality attribute of business software is neither measured nor measurable. A domain model does not quantify business fit—it makes it visible, discussable, and correctable.
And that is why it is ignored.
Not because it is unimportant—but because without a domain model, business fit is not merely unmeasured. It is unknowable.
Top comments (0)