The lathe doesn’t tell the machinist where to put the shaft. The oscilloscope doesn’t tell the electrical engineer where to route the signal. The crane doesn’t tell the civil engineer where to put the walls. Every mature engineering discipline figured this out early and never looked back: the physical problem drives the design. The tools are means, not ends.

Software was the exception — and for a remarkably long time.

I. The forty-year detour

For the first four decades of commercial software, the technology drove the design. Not the problem. “We’re building this in Java, so we’ll have classes, interfaces, factories, managers.” “We’re doing microservices, so the org chart follows the service topology.” “We’re using a relational database, so the domain model follows the schema.” The hammer determined the shape of the house.

Eric Evans’s Domain-Driven Design, published in 2003, is essentially just the software field catching up to what mechanical engineers knew before the Industrial Revolution. The domain is the driver. Technology is the means. You build a ubiquitous language around the business problem, not around the ORM. You define bounded contexts around what the business cares about, not around what’s technically convenient to deploy. You design aggregates around business invariants, not around database normalization rules.

A mechanical engineer picking up Evans’s book would find it baffling — not difficult, but baffling. Of course the physical problem drives the design. What else would drive it? But software engineers spent forty years letting the opposite happen, and DDD was the corrective that had to be written down, formalized, argued over at conferences, turned into 560 pages, because the field had genuinely lost the thread.

II. Why software lost the thread

Three structural reasons, none of them accidents.

The first is the malleability problem. Software has no physics. You can refactor, rewrite, restructure at will. Metal fatigues. Bridges collapse. Code just keeps running until you delete it. Without physical constraints to enforce correctness, the constraints feel artificial — negotiable — and they get negotiated away in favor of whatever the current tool or paradigm makes easy. Convenience fills the vacuum that physics left empty.

The second is the visibility problem. In software, the tools are made of the same material as the thing you’re building. The code that implements a factory pattern is indistinguishable, in substance, from the code that implements the business logic. There’s no obvious line between the hammer and the nail. When the scaffold and the building look identical, it’s easy to forget which is which.

The third is the youth problem. Mechanical engineering is thousands of years old. Civil engineering traces back to Rome and beyond. Electrical engineering is roughly 150 years old. Software is 80. Disciplines accumulate hard lessons slowly — through failures, litigation, collapsed structures, burned cities — and then codify them into standards, licensing requirements, professional norms. Software is still accumulating its first century’s worth.

III. The uncomfortable question

Evans published his diagnosis in 2003. It is now 2026, and the argument is not over.

Microservices architectures are still being designed around deployment convenience — what Kubernetes makes easy to run — rather than around domain boundaries. LLM integrations are being built around the model’s API surface, its token limits, its tool-use interface, rather than around the business problem the model is supposed to solve. The pattern hasn’t changed; only the technology has.

If DDD was already obvious in 2003, why does every new technology reset the clock? Why does each generation of engineers make the same mistake with fresh tools?

The most honest answer is that the bias toward the tool isn’t a correctable mistake. It’s a structural feature of how software gets built. New technology arrives with its own API, its own mental model, its own community of enthusiastic early adopters who’ve built their identity around it. Learning the tool is fast. Learning the domain is slow, expensive, and unglamorous. The incentives all point in the same direction: understand the technology, approximate the domain.

IV. Diagnosis without cure

Evans didn’t solve this. He named it. DDD was never a methodology that, once adopted, would fix the underlying drift. It was a reminder — a book-length argument that the domain is real and the tool is not — written because that reminder needed to exist.

Even in Boston, you need a license to install an electrical outlet, whether you hold a trade certificate or an engineering degree. The credential alone doesn’t suffice; the accountability structure does. Software has no equivalent. You declare yourself a software architect and design the system around whatever technology excites you this year. There’s no licensing board, no professional liability, no collapsed bridge to make the error legible.

Maybe that’s the deeper lesson. DDD is right about what should drive design. But should is doing a lot of heavy lifting in a field that has systematically avoided the accountability structures that would make it mean something.

The domain reasserts itself eventually — through maintenance costs, through failed migrations, through systems so tangled in their own technical idioms that no one can explain what they actually do. That’s the physics software does have: not material constraints, but the compounding cost of technical debt. It doesn’t kill anyone. It just makes everything harder, more slowly, until the project gets rewritten.

And the rewrite starts with the same conversation it always does: what problem are we actually solving here?

Further reading