Why the domain belongs at the heart of your software

Creating a domain layer in the heart of your software allows you to cleanly express the solution to the business problem without any entanglement of accidental complexity

A lot of architectural patterns talk about it—clean, onion, hexagonal. They all put domain concerns at the core of the system, but the reasons aren't always clear why we should do this, and most miss the most important one.

Why it matters that the domain is at the heart of your software

A domain at the centre lets you express the business problem cleanly, enabling all stakeholders to understand the system, without having to separate business logic from technical concerns.

Let's quickly define the two types of complexity that software systems contain. Essential complexity is the problem itself: what a contract is, which invariants must always hold. These are inherent to the system. Accidental complexity consists of the implementation-specific details of our chosen solution: whether we store data in SQL or files, how we format payloads, or how we manage retries.

Dealing with both types of complexity is real work. But it isn't the same kind of work, and mixing them makes both harder to understand and grapple with.

The database that answers the question or the message bus that carries the announcement is kept on the outside. The business doesn't care about those details; it only cares when rules are violated. Push the how outward so that the what stays readable.

The real payoff runs deeper than readability. A clean domain layer is where you capture an explicit model of the business, expressed in the ubiquitous language that domain experts and developers actually share. The code therefore stops being a loose interpretation of the business and becomes the model itself. Readability follows from that: a clean domain layer is the place a new developer, an auditor, or your future self can understand the system without first decoding layers of infrastructure. The domain layer is where the clarity lives.

Testing the domain and lowering infra costs

Two other major advantages come to the fore when the domain is at the heart of your software.

• Testing the domain becomes easier. Without dependencies on databases or networks, you can test the actual business rules directly instead of dealing with complex technical concerns. The tests remain fast, deterministic, and focused solely on the logic that matters.

• Infrastructure choices become less important. Swapping out a database or a message queue, while rare and not a real concern in most cases, becomes a lot easier. Because the domain only depends on abstractions, you can make these technical choices later or alter them with minimal impact on your business logic.

While both of these advantages flow naturally from a clean domain, they are downstream benefits. First and foremost, your tests transition from complex technical exercises into a clean, expressive representation of the business solution itself. By comparison, the ability to swap databases or message queues is merely a convenient technical byproduct—an argument that would look like an unnecessary overhead if presented as the primary goal. Ultimately, these benefits are valuable, but the core objective remains the same: domain clarity.

Pragmatism matters as well

A few honest caveats, because dogma here does more harm than good.

Be pragmatic about what you push out. Not every technical concern needs to become an elaborately abstracted port. If you treat logging as an external dependency that must be injected and inverted everywhere, you have added accidental complexity in the name of removing it. The priority order is what matters: first, can we express the business problem and its solution cleanly? Then, how do we orchestrate the technical side? The first question wins; the second is a tradeoff, not a rule.

Some domains are mostly technical. This whole approach shines when there is a real business domain to protect. If you are building something inherently technical —say a file-management tool—then there may be very little essential domain to isolate. Forcing the pattern will add complexity instead of removing it. This is often where the "this is just overhead" complaint comes from, and sometimes the complaint is right. The skill is telling the two situations apart: a rich business domain benefits enormously from a clean core; a thin technical one usually doesn't.

Why this matters even more with AI

There is a newer reason to care, and it reinforces everything above.

When you ask an LLM to change a system, it works within the limits of its context window. With an anaemic model—where the data is just bags of properties and the business rules are scattered across controllers, services, and queries—the AI has to sift through a lot of technical noise to find the actual signal. It reads one place, makes a change, and misses a rule living somewhere else. This is exactly the kind of fragmentation that produces production bugs, and is the same failure mode your software developers are spread thinly across the whole codebase.

A rich domain at the centre acts as a concise semantic map. Because the rules live directly with the data they protect, the AI (or a human developer) only needs to load the core domain to reason about the business logic. It does not have to understand the surrounding database or transport machinery to get the rules right.

Furthermore it’s a lot easier to validate the new code as a human if its only concern is “what does the domain model look like”. You have less code to review, and can focus purely on the business concerns.

In short

Keep the essential domain logic at the centre of your system and push the accidental complexity out. Your domain layer becomes an explicit, readable model of the business—making it easier for humans to maintain, simpler for AI to reason about, and effortless to test.

Give it a go yourself. If you have any questions, reach out.