Software that lasts: why we start with the domain — not with the stack

The technology question is rarely the hard one.

When a software initiative starts, the stack is usually the first topic. Which language, which framework, which cloud, which database. That is understandable — these are concrete, decidable questions. But they are rarely the questions a system fails on later.

Systems fail because nobody was able to describe precisely what actually happens in the business. Which events occur? Who triggers them? What follows from them? What has to stay traceable three years from now, when somebody asks why an invoice looks the way it does?

So we do not start with the stack. We start with the domain.

Event modeling: making the domain visible before code exists

Event modeling is a simple idea at its core: you lay out the events of a business process along a timeline and look at them together. Not as an abstract data model, but as the sequence of what actually happens. Quote created. Quote sent. Quote accepted. Order created. Delivery scheduled.

The decisive part is not the notation. The decisive part is who is in the room. Event modeling works because the people who own the process day to day can read the same representation as the people who build the system. There is no translation layer where misunderstandings quietly disappear and resurface three months later as a change request.

In almost every workshop of this kind the same thing happens: after roughly an hour, two people from the same department disagree about when exactly an order counts as accepted. That discussion could have happened later too — but then as a bug, an escalation, or an expensive renegotiation.

A model the business cannot read is not a model. It is an assumption in diagram form.

Event sourcing: traceability as an architectural principle

If you are thinking in events anyway, storing them is the obvious next step. That is event sourcing: the state of a system results from the sequence of events that led to it, instead of from a table that only knows the latest outcome.

That sounds like a technical detail. In practice it changes how an organisation relates to a system.

• History is answerable. "What was the state on 3 March?" becomes a query, not a reconstruction project.
• Errors are explainable. You see not only that a value is wrong, but which event produced it.
• Reports can come later. New views on the same events can be built afterwards without losing the past.
• Trust grows. Business units stop keeping a shadow spreadsheet once the system answers their questions reliably.

The last point matters most. Adoption is not decided in training. It is decided the moment somebody asks the system an uncomfortable question. If it answers convincingly, it gets used. If it does not, a spreadsheet appears next to it — and that spreadsheet is the real competitor.

Event sourcing is not an end in itself. It is the right choice when the domain is complex, history matters and decisions have to be justified later. For a simple administrative form it is overhead. We say so when that is the case.

Technology-agnostic means lean, durable, maintainable

We do not commit to one language or framework, because the right choice depends on context: on the team that will run the system, on its expected lifetime, on the integration landscape, on the capabilities already present in the company.

What we do commit to are three properties:

1. Lean. Every additional component is an additional point of failure and an additional reason why, two years from now, nobody wants to touch anything.
2. Durable. We pick building blocks that are likely to still be maintained in five years — not the ones getting the most attention this quarter.
3. Maintainable. The real test is not whether the system works today, but whether a new engineer can safely make a change within two weeks.

A system only the people who built it understand is not an asset. It is a liability with charm.

Ownership: somebody stands behind the result

The most common structural mistake in software initiatives is not technical. It is that responsibility is distributed across roles instead of people. A steering committee decides, a vendor delivers, a business unit tests — and if something does not fit, it was the interplay.

Ownership means something concrete to us: there is a named person who stands behind the technical course and the outcome. That person makes decisions, documents the reasoning so it can be re-read, and speaks up when the uncomfortable news arrives early rather than late.

Part of that is being willing to argue against our own mandate. When the simpler solution is the better one, we say so — even if the project gets smaller as a result. That is not idealism. It is the only way technical advice can be trustworthy at all.

What follows from this

Good software does not come from choosing modern tools. It comes from a properly understood domain, an architecture that takes traceability seriously, and a person who stands behind the result.

Everything else — language, framework, infrastructure — is a follow-up decision. Important, but downstream.

If you are facing an initiative and are unsure whether the domain has been described in a way that holds: that is exactly where we start.

What ownership looks like after go-live is described in ownership instead of roles.