DEV Community: Leon Pennings

Parts in transit - Why most distributed systems are prematurely complex

Leon Pennings — Sun, 10 May 2026 20:29:58 +0000

The incomparability problem

Here is a question that has no clean answer.

How do you know whether the architecture you chose was the right one?

Not right in the sense of working — most systems work, eventually, after enough effort. Right in the sense of optimal. Right in the sense that the complexity you introduced was warranted by the problem you were solving, and that a simpler approach would have cost more rather than less.

The honest answer, in most cases, is that you cannot know. Because the alternative was never built.

This is not a gap in the data. It is the mechanism of the problem. Most systems are built only once. There is no second system built with different assumptions, run for five years, and compared on total cost of ownership, ease of change, and operational stability. The counterfactual does not exist. Therefore the cost of the wrong choice — if it was the wrong choice — is permanently invisible.

None of this is to say that distributed systems cannot work. Many organisations have made them function, sometimes at considerable scale — usually through exceptional engineering discipline, strong platform investment, and genuine operational maturity. The question is different: how much of the total effort, over years, went into managing the consequences of the distribution itself, rather than advancing the domain? And would a simpler boundary choice have delivered more value with less sustained overhead? The counterfactual remains hard to prove, which is precisely why we need sharper prospective indicators.

And here is what makes the problem genuinely difficult: the entire industry tends to converge on the same patterns at the same time. When every team uses a similar stack, incurs similar coordination overhead, and grows to a similar size — those costs stop being visible as costs. They become the definition of what software costs. Normal and wasteful become indistinguishable.

So the question sharpens. If we cannot compare architectures retrospectively, is there anything we can measure prospectively — before five years have passed — that gives us a leading indicator of whether we are building something appropriately simple, or something unnecessarily complex?

There is. And it comes from an unlikely place.

The warehouse and the system boundary

Consider an order fulfilment operation. An order arrives. A picker walks to the rack holding the product, picks it, and places it on the assembly line. Routine.

Now consider what happens when that order is cancelled.

If the picker has not yet left the rack, cancellation is a system operation. One record updated. The state change is contained. The cost is negligible and the outcome is certain.

If the picker is already walking the floor — part in hand, mid-transit — the picture changes entirely. The picker must be located and reached. The instruction must be communicated and confirmed. The picker turns around, returns the part, re-shelves it in the correct position, and logs the return. The assembly line must be told the part is not coming and adjust accordingly. Each of those steps can fail. Each failure requires its own recovery. If the picker has already placed the part on the line, someone else must retrieve it, the line has already reacted to its arrival, and the cleanup compounds further.

The correction costs more than the original action. Not marginally more — multiplicatively more. More people, more coordination, more opportunity for secondary failure, and a system left in a state requiring verification before it can be trusted again.

This is the principle that makes architectural cost measurable before a system is built:

As long as domain actions happen within a single system boundary, the cost of failure is a rollback. The moment actions propagate outside that boundary, the cost of failure becomes coordination.

This is not a preference. It is a structural property of distributed systems, and it applies regardless of how well the coordination is engineered. You can manage the cost with better tooling. You cannot eliminate it. It is inherent to the boundary crossing.

The warehouse makes this visible in a way that software obscures. In the warehouse, you can see the picker walking. You can see the empty rack. You can see the stalled line. The cost of the part in transit is physically apparent. In software, the equivalent states — the uncommitted saga step, the unacknowledged event, the stalled compensating transaction — are invisible unless you built dedicated instrumentation to see them. The cost is identical. The visibility is not. That invisibility is precisely why the cost became acceptable.

The well-run warehouse minimises the time parts spend in transit, because parts in transit are the expensive state. The leading indicator of a well-designed system is the same: how much of the domain work happens within a single rollback boundary, and how much crosses outside it?

Rollbackability — the degree to which a failed action can be fully undone by the system without external coordination — is a concrete, prospective benchmark for simplicity. If you are designing a system and the failure path requires coordinating compensation across multiple services, you have already committed to a significant and permanent cost. The question is whether the benefit justified it.

In most cases, that question was never asked.

A concrete example: order creation

Take a canonical domain flow: an order is created, inventory is reserved, an invoice is generated, a shipment is planned. Four concepts. One business action. It either succeeds completely or it does not happen.

In a monolith with a well-modelled domain, this is the entirety of the orchestration:

java

@Transactional
public OrderConfirmation createOrder(OrderRequest request) {
    Order order       = new Order(request);
    Inventory.reserve(order);
    Invoice invoice   = new Invoice(order);
    Shipment shipment = new Shipment(order);
    return OrderConfirmation.of(order, invoice, shipment);
}

The database transaction is the system boundary. If anything fails, nothing happened. The domain concepts — Order, Inventory, Invoice, Shipment — do the work. The technology serves them. Rollbackability is total. The failure path costs nothing beyond the failed attempt itself.

This example is deliberately straightforward — but the principle holds as domain complexity increases. In fact, the more complex the domain, the more important it becomes that the infrastructure does not add noise. A complex financial workflow with regulatory holds is hard enough to reason about correctly without the additional burden of distributed coordination, partial failure states, and eventual consistency layered on top of it.

Now split those four concepts across four services. The business requirement has not changed by a single word. What changes is everything else.

The infrastructure required before writing a line of business logic

A message broker. Services cannot call each other synchronously if you want any resilience. Kafka or RabbitMQ: a three-node production cluster, topic design, schema registry, retention policies, consumer group monitoring, and a local development environment every developer must run and maintain.

Saga infrastructure. There is no transaction. Coordination must be made durable — if the orchestrator crashes mid-flow, it must resume from the correct step. This means a saga framework (Axon, Temporal, AWS Step Functions — each a substantial system with its own operational model and learning curve) or a hand-rolled saga state table with step tracking and a crash recovery process. Either way, there is now a fifth service whose entire existence is accidental complexity. It owns no domain concept. It exists solely because the transaction boundary was removed.

Distributed tracing. Four services produce four independent log streams with no shared identity unless you build one. Jaeger or Zipkin for the trace infrastructure. Every service propagates a correlation ID in HTTP headers, event envelopes, and log output. A log aggregation stack on top, because reconstructing an incident across four separate log streams without tooling is not a debugging workflow — it is an archaeology project.

Idempotency handling — in every service. Message brokers guarantee at-least-once delivery. The same event will arrive twice. Every consumer must handle this without creating two invoices or two shipments. An idempotency key strategy per event type. A deduplication store — typically a processed-events table — checked on every inbound message. This is not a framework you install. It is code you write, in every service, correctly, and maintain forever.

Compensating transactions — per failure path. The rollback equivalent. Designed, coded, tested, and maintained per service per failure scenario. For four services the paths are: inventory fails — cancel order; invoice fails — release inventory, cancel order; shipping fails — void invoice, release inventory, cancel order. Each compensation is a domain operation that must exist, be reachable, be idempotent, and be tested both in isolation and in combination. The failure paths grow as O(n²) with the number of services.

API contracts and versioning. In a monolith, a method signature change is a compiler error caught before deployment. Across services it is a potential production incident. OpenAPI specifications or event schemas in the schema registry. A versioning strategy for deploying new service versions while old ones are still running. Consumer-driven contract tests — an entirely new test layer that did not exist before.

Per-service operational overhead — multiplied by four. Each service needs its own CI/CD pipeline, its own database (shared databases between services defeat the architectural purpose), its own health checks, its own deployment configuration, its own secret management, and its own database migration strategy.

None of this is business logic. All of it requires expertise to operate correctly. In practice it means a platform or infrastructure team to own the broker and deployment infrastructure, application developers who understand distributed systems failure modes rather than just domain logic, and an ongoing operational load that scales with the number of services — not with the complexity of the domain.

The cost, made visible

The following table makes the prospective cost explicit — before the first line of business logic is written, and before five years have passed.

Concern	Monolith	Microservices	What the split actually costs
Atomicity and failure
Rollback on failure	Database transaction. One word.	Saga pattern. Hundreds of lines.	Design, code, and test a compensating action per service per failure path. O(n²) paths for n services.
Partial failure state	Impossible. Transaction is atomic.	Permanent possibility. Must be designed around.	Order exists, invoice does not. Every consumer of your data now reasons about completeness. Forever.
Consistency	Immediate. Guaranteed.	Eventual. A property you live with.	Not solvable with better tooling. A structural consequence of the boundary choice.
Infrastructure before business logic
Message broker	None.	Kafka or RabbitMQ. 3-node cluster.	Topic design, schema registry, retention policy, consumer group monitoring, local dev setup.
Saga / orchestration	None.	Axon / Temporal / hand-rolled plus a fifth service.	Durable saga state, crash recovery, step tracking. An entire service that owns zero domain concepts.
Distributed tracing	One stack trace.	Jaeger / Zipkin plus correlation IDs everywhere.	Every service propagates trace IDs in headers, event envelopes, and log output. Log aggregation stack on top.
Idempotency	N/A. Methods are naturally idempotent.	Required in every service. Always.	Deduplication store per service. Idempotency key strategy per event. Written, maintained, tested forever.
API contracts	Compiler. Free.	OpenAPI / schema registry plus versioning strategy.	Consumer-driven contract tests. A breaking change is a production incident. Another test layer that did not exist.
Per-service operational overhead
CI/CD pipelines	1	4+	Independent versioning, deployment windows, rollback strategies. Coordination overhead on every release.
Databases	1	4+	Independent migration strategies per service. Schema changes coordinated across deployment boundaries.
Local dev environment	One process.	4+ services plus broker plus docker-compose.	Onboarding measured in days not hours. Partial environments produce integration bugs that only appear in the full stack.
Debuggability and sustainability
Debug a production failure	One stack trace. One log stream.	Reconstruct a timeline across 4+ log streams.	Clock skew between services. Correlation IDs that were not propagated. Broker lag that shifted event order.
Bug surface	Domain complexity only.	Domain multiplied by accidental complexity.	Each async handoff is a new class of timing bug. Compensating paths run rarely, are tested inadequately, and fail in production.
Codebase legibility	Domain is the code.	Domain distributed across event schemas and API contracts.	"What does order creation actually do?" has no single answer. The behaviour is implicit in subscriptions across four codebases.
Maintenance cost over time	Proportional to domain complexity.	Domain plus accidental complexity.	Accidental complexity does not reduce over time. Services accumulate. Contracts fossilise. Framework versions break. Teams leave.
Scaling
Unit of scale	The atomic action. Run more instances.	Individual steps — which are not the bottleneck.	Invoice creation and shipment planning are simple writes. They are not traffic hotspots. The decomposition solves a problem that does not exist.
Infrastructure to scale	Load balancer plus N identical instances.	Everything above, multiplied.	All the saga, broker, and tracing infrastructure exists solely to reconstruct what the database transaction provided for free.

The scaling argument that is rarely examined closely

The case for microservices typically rests on scalability. You can scale the parts that need scaling independently, rather than scaling everything together.

This sounds rational until you ask what actually needs scaling.

In an order creation flow, the bottleneck is almost never the invoice logic or the shipment record creation. These are simple writes that happen once per order. The thing that needs scaling is the number of concurrent orders being created — the atomic action as a whole.

Scaling the atomic action requires a load balancer and N identical instances of one deployed artefact. Each instance connects to one database. The database handles concurrent transactions reliably, as it has for decades. The infrastructure cost is a fraction of the distributed alternative. The operational complexity is a fraction. The failure surface is a fraction.

A well-modelled core domain is not large. This is not an aspiration — it is what remains when accidental complexity is removed. The essential logic of order-to-shipment fits comfortably in one process, understood by one team. What makes codebases large is not the domain. It is frameworks imposing their structure on domain code, duplication caused by unclear boundaries, accidental complexity accreting around poor models, and boilerplate generated by architectural patterns that do not fit the problem.

Strip those out and the core is small, fast to deploy, cheap to run, and trivially scalable as a unit.

The industry asked "how do we scale the parts?" before asking whether the parts needed to be separate. It then built an entire ecosystem of frameworks, patterns, and operational infrastructure to answer the first question — all solving a decomposition problem that, in most cases, did not need to exist.

When distribution is the right answer — and when the arguments do not hold

Distribution has genuine use cases. They are narrower than the industry's adoption rate suggests, and several of the most commonly cited justifications do not survive close examination.

Physical and regulatory constraints

The standard argument: if data must live in a specific jurisdiction for regulatory reasons, you need a distributed architecture.

The better answer: replicate the full domain logic into that regulatory cell. The atomic action stays atomic. The cell — with its own deployment, its own database, its own complete stack — is the unit of distribution. What you do not do is split the domain action across a jurisdictional boundary, routing parts of it between regions. That creates the coordination cost of distribution without the isolation that justified it. The constraint is geographic. The solution is geographic deployment of the whole, not decomposition of the parts.

Independent scaling profiles

The standard argument: if one component needs more scale than others, separating it avoids scaling everything unnecessarily.

The better answer: the cost of splitting a single component out of an otherwise coherent domain action is large, fixed, and permanent — as the table above makes clear. The question is not only "does this component need more scale?" but "does the benefit of isolating its scale exceed the full coordination cost of the split?" In most cases it does not, because the component that appears to need independent scaling is rarely the actual bottleneck under measurement, and because scaling the whole is cheaper than the industry assumes. If there is no compelling reason not to scale everything, scale everything. Simplicity requires a reason to abandon it, not a reason to adopt it.

Organisational boundaries

The standard argument: Conway's Law — systems tend to mirror the communication structures of the organisations that build them. If teams are separated, align the architecture accordingly.

Conway's Law is a useful observation in retrospect. It describes what tends to happen when architecture is not deliberately managed. It is not a prescription, and it should never be used as one. Using it as a justification for a service boundary is encoding organisational structure permanently into the system — and paying the technical cost of that boundary in every sprint, by every developer, for the lifetime of the product.

The cost of an artificially introduced service boundary compounds over years. The cost of reorganising a team is paid once. The engineering should define the ideal architecture with as few compromises as possible. The organisation should be arranged to serve that architecture, not the other way around. This pays dividends — perhaps not in year one, but reliably by year five, and every year thereafter. Teams that succeed with microservices often do so despite the architecture, through heroic platform investment and operational discipline. The patterns can be made to work. The deeper question is whether they were the right starting point for the domain in front of them.

Genuinely independent domain concepts

This is the one case where distribution has a legitimate technical argument — and even here, the bar should be high.

Domain concepts are genuinely independent when they have no transactional relationship with each other. Not merely different in name or ownership, but different in the sense that one completing or failing has no bearing on the integrity of the other. A recommendation engine and a payment processor are genuinely independent. An order and its invoice are not.

The strongest version of this argument comes from systems with a fundamentally asymmetric workload — a platform where reads vastly outnumber writes, where the read path has no transactional requirement, and where the scale difference between the two is large and proven. A social platform where the overwhelming majority of requests are reads with no transactional requirements is a system where isolating the read path separates two genuinely different kinds of work with different resource profiles and different failure tolerances.

But this is a workload argument supported by measurement, not an architectural principle applied by default. It applies to a small fraction of the systems that have adopted microservices, and it should be reached by evidence, not anticipated in advance.

Three tests before splitting a boundary

The rollback test. If this action fails halfway through, what does recovery cost? If the answer is a database rollback, the action belongs inside a single boundary. If the answer is a coordinated sequence of compensating calls across multiple services, each of which can itself fail, ask whether that coordination cost was consciously accepted — or simply inherited from a pattern that was never examined.

The scaling test. Which specific step in this action is the measured bottleneck under current or near-term load? Not the theoretical bottleneck. The step that is demonstrably the constraint today, under real conditions. If the answer is none of them individually, the action does not need decomposition. It needs more instances of the whole.

The standup test. In the daily standup, what language does the team use? If the items are about services, pipelines, brokers, schemas, and migrations — the team is working on accidental complexity. If the items are about domain concepts — what an order means, who owns a responsibility, what a rule actually requires — the team is working on the right problems. You do not need a cost model to apply this test. You need one conversation.

Measuring it in a system you already have

If these tests apply prospectively, they also apply to systems already in production. A short audit reveals more than any architecture review.

Count the sagas. How many business capabilities require a saga or orchestrator to complete? Each one is a boundary crossing that converted a rollback into a coordination problem. The number tells you how much of the domain is currently in transit.

Measure the standup ratio. Over two weeks, track how many standup items are about infrastructure, services, pipelines, and schemas versus domain concepts, rules, and business questions. The ratio is a direct reading of how much of the team's daily energy is absorbed by accidental complexity.

Trace a failure end to end. Pick a recent production incident. Count the number of log streams, services, and correlation IDs required to reconstruct what happened. That reconstruction cost — in time, in tooling, in expertise — is paid on every incident. It is the maintenance tax of the boundary choices made at design time.

Apply the migration heuristic. A well-modelled monolith can be split later, when measurement proves a specific boundary is warranted. A distributed system can rarely be reassembled cheaply once the boundaries have fossilised into contracts, event schemas, and separate team ownership. Optionality has value. The simpler starting point preserves it. The complex starting point spends it immediately, in exchange for flexibility that may never be needed.

First principles

There is nothing novel in the argument this article makes. It is an application of principles that engineering has held for as long as engineering has existed.

Minimise the moving parts. Every component that can fail will eventually fail. Every interface between components is a surface for misunderstanding, for version drift, for timing errors that only appear under conditions nobody anticipated. The system with fewer moving parts is not the primitive system — it is the disciplined one.

Solve the problem in front of you. The system that is over-engineered for scale it has not reached, for distribution it does not need, for independence that its domain does not have — that system is not prepared for the future. It is burdened by it. It is paying, today and every day, for problems it may never have.

Prefer reversibility. The decision that can be undone when it proves wrong is worth more than the decision that cannot, regardless of how confident you are at the time. A monolith that can be split later, when the evidence demands it, is a better starting point than a distributed system that cannot be reassembled after the evidence proves the split was premature.

Measure before you commit. The incomparability problem — the fact that the alternative architecture was never built, so its cost can never be directly compared — cannot be fully solved. But its worst effects can be mitigated by demanding evidence before committing to complexity: evidence of the scaling requirement, evidence of the domain independence, evidence that the coordination cost is worth the benefit it buys.

The software industry has a habit of adopting solutions before fully understanding the problems they were designed to solve, and then normalising the cost of those solutions until the cost becomes invisible. The distributed systems patterns that dominate today were developed by organisations with genuine physical distribution requirements, at a scale that a small fraction of systems ever reach. They solved real problems. They are also expensive, complex, and failure-prone in ways that compound over time and rarely appear on the original architectural diagram.

The question to ask, before any architectural decision, is not "how do others solve this?" It is "what does this problem actually require?" Start from first principles. Follow the cost. Build the simplest thing that genuinely solves the problem in front of you. Treat every boundary crossing — every point where a database rollback becomes a distributed coordination problem — as a commitment with a known, permanent price tag.

Because it will cost exactly that. Invisibly, continuously, and for as long as the system runs.

AI can build anything except an understanding of what you are building

Leon Pennings — Mon, 04 May 2026 08:28:51 +0000

There is a distinction in software development that the industry has spent twenty years pretending doesn't exist. It is the distinction between building software and understanding what you are building. The first is implementation. The second is engineering. They are not the same thing, they do not require the same skills, and conflating them is the single most expensive mistake a development organisation can make.

The mistake is now being turbocharged by AI. But to understand why, you first need to understand what was already broken.

Part One: The 85% Nobody Talks About

Two Kinds of Work

Ask most developers how long it takes to build a feature and they will give you an implementation estimate. How long to write the code, wire up the endpoints, get the tests green. That estimate — the part where fingers meet keyboard — accounts for roughly 10 to 15 percent of what building good software actually requires.

The other 85 to 90 percent is structuring. Understanding what the system is. Identifying where things belong, not just where they are needed. Naming the concepts correctly. Finding the natural boundaries in the domain. Modelling the business so that the code expresses it rather than merely approximating it.

This is the work that determines whether a system is maintainable in year five, extensible in year seven, or being quietly replaced shortly after.

Most systems are being replaced by year seven. The 85% was skipped.

Three Approaches, One Honest Assessment

There are essentially three ways to approach building a system, and only one of them qualifies as engineering.

The first is upfront design. You model the domain completely before writing code. The risk is rigidity — the model is fixed before the code has had a chance to reveal its gaps. Reality has a way of not fitting the diagram.

The second is evolutionary modelling. You begin with a hypothesis about the domain and use code as a feedback instrument. The model and the implementation refine each other continuously. An hour into implementation the starting model may have changed dramatically — a new concept discovered, a responsibility reassigned, a boundary redrawn. That is not failure. That is the process working. The model remains the authority throughout, but it is a living authority — responsive and correctable, never frozen.

The third approach is template filling. You select a framework. You receive a user story, which functions as a work order. You find the place in the template where this kind of story goes. You implement it there. You close the story.

There is no model in this process. There is no conceptual centre. The framework is the authority, and the code documents what the framework was configured to do. Frameworks turned engineers into assembly line workers, and the Singleton Paradox — the impossibility of comparing the system that was built using approach A against the system using approach B that was never built — hid the cost. This is not a different kind of design. It is the absence of design, wearing design's clothes.

The Model as Construction Tool, Discovery Tool, and Filter

The perception is that domain modelling is slow — that it delays visible output while the team thinks instead of ships. The reality is the opposite.

A domain modelling session is twenty to thirty minutes at a whiteboard, followed by code that shapes the actual business interactions. This is not a prototype or a spike. It is production code — the domain coming into existence, business logic finding its natural form. By the end of the first day there is working code that expresses what the business does. The template developer, meanwhile, is configuring YAML, wiring injections, setting up repositories. The motion looks productive. Not a line of it describes the business.

This is the construction side of what a domain model does. But it has two further functions that are equally important.

It is a discovery tool. When implementation is hard — when a concept resists being placed, when a responsibility has no natural home — that difficulty is information. The model is telling you something is missing, or something is wrong. A trial-and-error developer experiences this friction as a local problem to solve locally. A modelling developer experiences it as the domain asking to be understood more precisely. The response is not a workaround. It is a model refinement.

It is also a filter. If a behaviour cannot be fitted naturally into the model — if no object has a clear reason to own it, if it contradicts what the model already captures — that resistance is a signal. Either the model needs a new concept, or the behaviour itself does not belong in the system. The model's inability to absorb something cleanly is not a failure of the model. It is the model doing its job, filtering out accidental complexity dressed as a requirement. If you cannot fit behaviour into the model, you probably do not need it.

A domain model is simultaneously the thing you build with, the instrument that tells you what you are missing, and the filter that tells you what does not belong. The industry has largely stopped building them.

Essential Complexity vs Accidental Complexity in Code

The essential/accidental distinction from Fred Brooks is not just an architectural principle. It applies at the level of every object, every responsibility, every line of code — and getting it right at that level is what separates systems that age well from systems that don't.

Consider a practical example. When building a system that communicates with external services, the essential complexity is what those communications are — what a request contains, what posting requires, what the business needs to express. The accidental complexity is how those communications happen — the transport protocol, the connection handling, the session management, the specific library in use this year.

Model the responsibilities first. A client object owns the mechanics of communication. A request abstraction defines what communication content looks like. A posting variant adds what posting specifically requires. These are modelled as business responsibilities, technology agnostic. The how — whether the underlying transport is HTTP, MQ, or a database — sits entirely behind those responsibilities, invisible to everything that depends on them.

The consequence is significant. The technology can change completely — from web service to message queue to direct database write — without touching a single line of the business logic that constructs and uses those requests. The essential complexity is stable. The accidental complexity is genuinely replaceable.

This is not an interface trick. It is what happens when you model responsibility first and let technology serve the model, rather than letting technology shape what responsibilities are possible. The difference only becomes visible when the technology needs to change — which it always does, eventually. At that point, a system where accidental complexity was kept genuinely separate from essential complexity absorbs the change quietly. A system where the framework grew roots into the business logic requires the business logic to change when the framework changes. The technology that was supposed to serve the domain ends up constraining it instead.

The User Story as Work Order

Something specific happened to the user story as agile methodology was industrialised. It began as an invitation — a prompt to have a conversation with a domain expert, to understand a piece of the business well enough to model it. It became a specification. Then a work order. Then a checkbox.

In its current form the user story arrives at the developer already closed. The conversation with the domain expert happened upstream, in refinement, in planning, in the product owner's head. The developer receives a summary and works from that. The question the developer asks is not "what is this telling me about the domain" but "where in the template does this go."

The diagnosis is visible in what developers say when asked where the hard part of a system is. A template developer describes framework complexity — which abstraction to use, which pattern applies, how to configure the integration. A modelling developer describes domain complexity — what the business is actually doing here, what concept is missing, what existing object is being asked to carry weight it was not designed for.

These are not the same question. They do not produce the same system. And over seven years, the difference between the systems they produce is not marginal.

Where Things Belong vs Where They Are Needed

The most consequential difference between template filling and domain modelling is not visible in the first sprint. It becomes visible in maintenance, and it compounds with every passing year.

A template developer fixes problems where they occur. A table misbehaves on page B, so page B gets adjusted. The fix works. The story is closed. What is not visible is what has just happened structurally: page B now owns part of the table's behaviour. The table behaves one way on page A and another way on page B, and both pages carry part of the responsibility for what the table does. The next developer to touch either page must understand both. Maintenance has doubled, invisibly, for that one component.

A modelling developer asks a different question: what owns this behaviour? The answer is the table itself. The table owns its own presentation. The page owns its usage of the table. A fix to the table propagates everywhere the table is used, because behaviour lives in the component, not in the pages that consume it.

This is not an aesthetic preference. It is the mechanical difference between maintenance costs that stay flat and maintenance costs that compound.

Multiply this pattern across a codebase over five years and you have the prototype in production — a system held together with toothpicks, paperclips, and glue, where every workaround is load-bearing and every change requires understanding not what the system is, but what it has become.

The difference between fixing the problem where it occurs and fixing it where it belongs is the difference between prototype code and production code. At scale, it is the difference between a system that costs the same to maintain in year seven as it did in year one, and a system that is already being rewritten.

The Contradiction Problem

There is a specific consequence of building without a domain model that becomes critical at scale. It is underappreciated, and AI makes it significantly worse.

A domain model is not just a design preference. It is a contradiction-detection mechanism.

When business logic has a conceptual centre — a well-named domain object that owns its own behaviour — contradicting rules become visible. If two requirements make incompatible demands on the same object, you encounter the conflict when you try to model it. The structure surfaces the problem before it reaches production.

When business logic is scattered — across service methods, event handlers, configuration files — contradictions are invisible until they collide in production. Two requirements can contradict each other completely and coexist undetected for months, because there is no common reference point that would make the conflict visible. The system implements both rules, resolves the conflict arbitrarily at runtime, and produces behaviour that nobody designed and nobody can explain.

CQRS, microservices, and event-driven architecture were proposed, in part, as responses to the complexity that accumulates without a domain model. The tragedy is that they add architectural elaboration without supplying the missing conceptual centre. They do not make contradictions visible. They distribute logic across more moving parts, which makes contradictions harder to see, not easier. The problem is obscured by the solution.

Part Two: AI Became the Framework

The Same Pattern, Faster

Which brings us to the present moment, and to the claim that AI is transforming software development.

It is. But not in the way most of the conversation assumes.

There are two ways to think about AI-assisted development, and they map precisely onto the distinction between design and template filling established in part one.

AI is revolutionary in the sense that you conceive what you want, express it, and something builds it. The implementation barrier has been dramatically lowered. Code that would have taken days takes minutes. This is real and significant.

But AI-assisted development is also pure template filling. You are not modelling. You are instructing. The output is code that documents what the prompt said, with AI as the framework. The assembly is faster, the templates are more flexible, the results are more immediately impressive. The absence of a modelling process is identical.

And it inherits both failure modes simultaneously.

From upfront design, it inherits rigidity at the point of prompting. The model — such as it is — is fixed in the prompt. The code cannot talk back, because you are not in dialogue with it. You are receiving output. The feedback loop that makes evolutionary modelling work — where implementation friction becomes structural insight — is broken. The AI absorbs the friction. You never feel it. You never learn from it.

From template filling, it inherits the absence of a conceptual centre. The logic lives in the prompts, scattered and unreconciled, exactly as it lived in the fat services and event handlers before it. Except now it is even less visible, because a service class at least had a name and a location in a codebase. A prompt has neither.

The framework abstracted the developer from the infrastructure. AI abstracts the developer from the code. Each layer of abstraction makes "it works" faster to achieve and the absence of a domain model harder to see.

What the industry is currently calling "AI produces spaghetti" is not a new problem. It is framework templating amplified. The spaghetti was already there. AI makes it faster to produce, more voluminous, and more convincing — because it arrives in clean syntax with passing tests. The structural absence underneath looks better than ever.

AI did not replace the framework. AI became the framework. And it inherited the same problem the framework always had — it can build anything except an understanding of what you are building.

The Maintenance Proposition Does Not Hold

The proposition being made for AI-assisted maintenance is that rewrites are now cheap, so structural problems do not accumulate the same way. This deserves examination.

A rewrite can reproduce the syntax of a system faster than ever before. What it cannot do is verify that the rewrite is correct in the only sense that matters for a business system — that it accurately represents what the business actually does. Correctness here is not syntactic. It is semantic. It requires a reference against which to check the implementation.

The reference is the domain model. And the domain model is exactly what was never built.

So the rewrite, however fast, produces new code that implements the same contradictions, the same scattered logic, the same implicit assumptions. It is not a fix. It is a reprint. The toothpicks are replaced with newer toothpicks. The paperclips are shinier. The structure is identical.

Consider the contradiction problem at scale. Two prompts with conflicting business logic — you will probably spot it. Twenty — possibly. Eighty — almost certainly not. There is no structure that makes the contradiction visible. A rewrite from those eighty prompts does not resolve the contradiction. It reproduces it in fresh syntax. And in another cycle, the same conversation about rewriting will begin again, for the same undiagnosed reasons.

What Disappears and What Doesn't

Frameworks will likely disappear, and probably sooner than the industry expects. Hibernate exists because writing database session management by hand is tedious and error-prone for humans. AI has no such limitation. It can write the queries, manage the sessions, handle the mapping — contextually, specifically, without a generic abstraction layer designed for every possible use case. The framework was a productivity tool for human limitations. As those limitations are removed, the justification for the framework dissolves. This is not a loss. Frameworks were always accidental complexity — complexity introduced by tools rather than by the problem itself.

But the domain model does not disappear with the framework. It becomes more critical. Because the framework, for all its costs, at least imposed some structure. Generic, clumsy, domain-agnostic structure — but structure nonetheless. Without it, and without a domain model, the only thing standing between a system and total architectural entropy is the conceptual model in the developer's head.

Or its absence.

The Skill That Cannot Be Prompted

The ability to model a domain — to hold a structural representation in your head, refine it through implementation, and express it in code that means something beyond its own execution — does not appear to be a skill that AI can supply or that prompting can replicate.

It appears to correlate with a specific kind of spatial reasoning: the ability to see a three-dimensional object from its two-dimensional components, to hold structure in the mind and manipulate it without losing the whole. Developers who have this skill behave differently when they encounter implementation friction. Where a template developer sees a local problem to solve locally — a fix applied where the problem occurs rather than where it belongs — a modelling developer sees structural information. The friction is the domain asking to be understood more precisely. The response is not a workaround. It is a model refinement.

You cannot prompt your way to that response. The prompt eliminates the friction. And the friction was the signal.

The Only Honest Measure

There is a simple diagnostic for whether a system was built or merely assembled. Apply it after seven years.

Is maintenance getting cheaper or more expensive? A well-modelled system gets cheaper — the model matures, the team internalises it, changes become faster as understanding deepens. A template-filled system gets more expensive, as accidental complexity compounds and each change must navigate the accumulated residue of earlier decisions made without a model.

Are new requirements getting faster or slower to absorb? A well-modelled domain accelerates — each addition deepens understanding and reveals where the next extension naturally fits. A system without a conceptual centre slows — each requirement negotiates with the existing tangle rather than extending a coherent structure.

Has the rewrite conversation started?

The rewrite is not a sign of business ambition or technical progress. It is the bill arriving for the 85% that was skipped. And it will reproduce the conditions that made it necessary, because the organisation never learned what actually went wrong. The diagnosis will be "technical debt" or "legacy architecture." Rarely will it be accurate: no domain model was ever built, and without one, the rewrite begins the same accumulation from sprint one.

AI makes none of this cheaper in the long run. It makes the first two years cheaper and the subsequent five more expensive, because the prototype is produced faster and looks more convincing, and the discovery that it is a prototype comes later and costs more.

The 85% cannot be prompted. It cannot be templated. It cannot be abstracted away by a sufficiently powerful framework, however intelligent that framework becomes.

It requires understanding what you are building.

That has always been the hard part. It remains the hard part. And the industry's increasing sophistication at avoiding it is not progress.

It is a more expensive way of arriving at the same rewrite conversation, on roughly the same schedule, having learned roughly the same nothing.

How to Test Whether Your Software Solution Actually Fits The Problem

Leon Pennings — Tue, 28 Apr 2026 06:04:11 +0000

Every application is built once.

There is no second version of the same system, built with different architectural assumptions, run in parallel for a decade, and then compared on maintenance cost, team size, and requirement absorption speed. The alternative is never built. The counterfactual never exists. This is the Singleton Paradox applied to software: because each system is unique, there is no external reference point against which to judge whether it is a good solution to its problem — or merely the only solution anyone bothered to build.

This matters more than it might appear. It means that the quality of an architectural decision can never be measured by comparison. You cannot park the well-modeled system next to the poorly-modeled one and read off the difference. The poorly-modeled system is the only one that exists. So when it becomes expensive to maintain, slow to change, and eventually impossible to extend, those outcomes get attributed to the problem — the domain was complex, the requirements changed, the business grew — rather than to the solution. The solution is never put on trial, because there is nothing to try it against.

The Singleton Paradox does not just make good architecture hard to prove. It makes bad architecture hard to see. The absence of contrast is not neutral. It actively shapes what gets treated as normal. Rising maintenance costs are normal. Growing teams are normal. Slowing feature velocity is normal. Rewrites every seven to ten years are normal. None of this is normal in the sense of being inevitable. All of it is normal in the sense of being what happens when accidental complexity (Fred Brooks' term for the complexity introduced by tools and decisions rather than by the problem itself) compounds over time, and when there is no alternative visible to suggest it could be otherwise.

This creates a specific and solvable problem. If external comparison is unavailable, the only honest measure of whether a system is a good fit for its problem is internal. Not how it compares to another system that was never built, but how it behaves against time. Does it get easier or harder to operate? Does it get cheaper or more expensive to change? Does it remain stable as the domain evolves, or does it accumulate fragility with each passing year?

Those questions have answers. And the answers, taken together, constitute the only reliable verdict on whether the solution fit the problem.

The Ten-Year Cost Test

That internal measure can be made concrete. The Ten-Year Cost Test is a diagnostic any organisation can apply to its own systems — not a comparison against an alternative that was never built, but a set of questions about whether the current architecture is winning or losing against time. The threshold of ten years is not arbitrary. A system that cannot survive a decade without a rewrite has not been maintained; it has been replaced. And replacement, however it gets framed, is the system announcing that it was not a good fit for the problem it was built to solve.

The test is simple. After ten years in production, a well-designed system should satisfy all of the following:

Maintenance cost is the same or lower than year one. As the domain model matures and the team's understanding deepens, maintenance should become cheaper, not more expensive. The team knows where everything lives. The rules are explicit and localised. A change that took two days in year one should take two hours in year ten, because the model has been refined and the team has internalised it.

New requirements are absorbed faster as the system matures. A well-modeled domain does not merely keep pace with new understanding — it accelerates. Each addition deepens the team's knowledge of the model and reveals where the next extension naturally fits. When the business learns something new — a new product type, a new regulatory constraint, a new class of customer — the model should be able to absorb it with decreasing effort over time, not constant effort. If absorption speed is flat, the domain model is adequate but not right. If it slows, the model is failing. A well-modeled system gets easier to extend the longer it has been understood.

The team size required to maintain it has not grown significantly. This is perhaps the most honest measure of architectural health. A system that requires more people every year to maintain the same functionality is a system where accidental complexity is compounding. Each new developer adds coordination overhead. Each new layer of abstraction requires more people to understand it. A well-modeled system with low accidental complexity should be maintainable by a small, stable team indefinitely.

The application is as stable or more stable than it was initially. Stability should increase over time as the model matures and edge cases are understood and handled. If the system becomes less stable over time — more incidents, more unexpected interactions, more fragile integrations — accidental complexity is winning.

The cost of running it has not grown faster than the business it serves. Infrastructure costs, operational overhead, and support burden should scale with business growth, not with architectural entropy. A system that costs significantly more to run in year ten than it did in year one, while serving the same number of users, has a structural problem.

Apply this test honestly to any system you have worked on for more than five years. The results are rarely comfortable.

What the Industry Data Actually Shows

Before examining how the average project scores on this test, an important caveat is necessary. Rigorous longitudinal data comparing domain-first versus framework-first approaches over ten-year periods essentially does not exist in published form. The industry does not measure what it should measure. Deployment frequency, recovery time, and project delivery success rates are tracked. Total cost of ownership relative to architectural approach over a decade is not.

This absence is itself the Singleton Paradox operating at industry scale. Nobody ran the controlled experiment. Nobody built both versions of the same system and compared them over ten years. So the precise cost differential between approaches is genuinely unknown in the scientific sense — even though the directional evidence is consistent and substantial.

What does exist:

The CISQ estimated in 2022 that poor software quality costs US organisations approximately $2.41 trillion annually, with a significant portion attributable to accumulated technical debt. The direction of travel is clear even if the precise attribution to architectural choices is not.

The Standish Group CHAOS Report has tracked project success rates for decades. Despite continuous evolution of methodology — agile, DevOps, cloud-native — the underlying success rates have not dramatically improved. This implies the problem is structural rather than methodological. Better processes applied to the wrong architecture produce better-managed failure, not success.

The DORA research — Google's annual State of DevOps reports, now covering over 39,000 professionals — shows a persistently bimodal distribution. The 2024 report found that elite performing teams have change failure rates around 5% and recover from incidents in under an hour. Low performing teams have significantly higher failure rates and recovery times measured in days or weeks. Only 19% of organisations reached elite performance. The low performance cluster, meanwhile, grew from 17% to 25% of respondents between 2023 and 2024. The distribution is not a bell curve. It is two distinct populations. Architecture and approach appear to be the differentiating variable, not team size, budget, or industry.

Amazon Prime Video published a case study in 2023 describing a 90% infrastructure cost reduction after consolidating a distributed microservices monitoring service into a single process — a result specific to that service, not a platform-wide architectural overhaul, but instructive precisely because the team at Amazon chose to be candid about it. Segment, a data platform company, published a similar account. These are self-selected — organisations that consolidated and saved money are more likely to publish than those that saw no benefit — but they are directionally consistent with the argument being made here.

A McKinsey and University of Oxford study of more than 5,400 IT projects — conducted in 2012 and still the most comprehensive published dataset of its kind — found that large IT transformation projects run on average 45% over budget, 7% over time, and deliver 56% less value than predicted. That is first delivery. The trajectory over the subsequent decade is harder to find in rigorous published form — which is itself telling.

Scoring the Average Project

With that context, here is an honest assessment of how the average project scores on each dimension of the Ten-Year Cost Test. These are not precise figures — the data does not support precision — but they represent the consistent direction of the evidence.

Maintenance cost rises significantly on the average project. Industry estimates consistently place maintenance at 60–80% of total software lifecycle cost, and that proportion grows over time rather than shrinking. On framework-first systems, the annual upgrade cycle alone — broken dependencies, reworked configuration, revalidated integrations — consumes engineering capacity that produces zero business value. In the worst cases, maintenance costs grow 800% or more over a decade, eventually triggering a rewrite. In the best cases — domain-first systems with low accidental complexity — maintenance costs stay flat or fall as the model matures.

Requirement absorption speed slows materially on the average project. In a well-modeled system, new requirements should get faster to implement over time — not slower — as the team's understanding deepens and the model reveals where each extension naturally fits. On the average project, the opposite happens. What starts as a two-week feature becomes a two-month project by year five, as each new requirement must navigate accumulated accidental complexity. In distributed systems, a single business rule change triggers API contract renegotiation, versioning decisions, cross-team coordination, and staged deployments. In the worst cases, the system effectively stops absorbing new requirements — every change becomes a major project and the business routes around the software rather than through it. In the best cases, requirement absorption accelerates as the model matures. Flat speed is a warning sign. Slowing speed is a verdict.

Team size grows on the average project. Industry observation consistently shows teams of two to three times the original size by year ten, maintaining the same functional scope. In the worst cases — full microservices architectures with dedicated platform, SRE, and DevOps functions — the team exists primarily to manage its own infrastructure rather than to serve the business. In the best cases, the team stays small and stable. Three developers. Five hundred domain objects. Fifteen years.

Stability declines on the average project. DORA data shows that low-performing teams — the majority — have change failure rates approaching fifty percent and recovery times measured in weeks. Production increasingly becomes the final validation environment because the integrated system only meets real conditions there. In the worst cases, the organisation develops a chronic incident culture where production instability is treated as a fact of life rather than an architectural signal. In the best cases, stability improves over time as the model matures and edge cases are properly handled.

Running costs grow faster than business value on the average project. The shift to cloud computing made infrastructure costs more visible but did not reduce them. Microservices architectures run fifty to two hundred containers where a monolith needs three to five, with corresponding cost differentials. In the worst cases, infrastructure cost grows an order of magnitude while business capability grows modestly. In the best cases, running costs remain proportional to business growth throughout the system's life.

The rewrite conversation starts on the average project around year seven. In the worst cases, the conversation starts at year three or four — the system has already become unmaintainable before it is fully understood. In the best cases, the conversation never happens. The system absorbs new requirements, accommodates new technology at its boundaries, and continues to serve the business indefinitely.

The Inverse Is Also True

The data does not merely show that the average project fails the Ten-Year Cost Test. It shows that failure is the expected outcome — so expected that the industry has stopped treating it as failure.

Rising maintenance costs are attributed to business complexity rather than architectural choices. Growing teams are treated as evidence of business success rather than architectural inefficiency. Slowing requirements are explained by changing priorities rather than accumulated accidental complexity. Declining stability is managed with better monitoring rather than addressed at its source. The rewrite conversation is framed as modernisation rather than recognised as the bill arriving for choices made before the domain was understood.

This normalisation is the most dangerous consequence of the Singleton Paradox operating at industry scale. When everyone is paying the same inflated price, the inflated price becomes the reference point. The cost of accidental complexity is not visible as a cost. It is visible as the cost of software — the natural, inevitable, irreducible price of building systems.

It is not natural. It is not inevitable. It is not irreducible.

It is the compound interest on a specific set of choices, made consistently, across the industry, before domains are understood. Choices that look like engineering because everyone makes them. Choices that the Singleton Paradox ensures will never be clearly falsified, because the alternative is never built.

The Rewrite as the Final Verdict

There is one more signal worth examining. It requires no data, no research, no longitudinal study. It is available in almost every organisation that has been running software for more than a decade.

The rewrite conversation.

When someone in your organisation argues that the current system cannot support where the business is going — that it needs to be modernised, migrated, rebuilt on a new platform — that system has already announced its verdict on the Ten-Year Cost Test. The rewrite is not a sign of business ambition. It is the bill arriving.

The tragedy of the rewrite is not its cost, though the cost is substantial — typically measured in millions and years. The tragedy is what happens after. The new system almost always makes the same choices. The same framework is selected before the domain is understood. The same patterns are applied before the business concepts are named. The same accidental complexity is introduced in the first sprint and compounds through the same lifecycle.

Because the Singleton Paradox means the organisation never learned from the previous system what actually went wrong. The previous system ran in production. The pipeline was green. The architecture was recognised. The failure was economic and temporal — too slow, too expensive, too fragile to change — not functional. And economic, temporal failure is invisible until it isn't. By the time the rewrite conversation starts, the diagnosis is usually "technical debt" or "legacy architecture" or "we outgrew it." Rarely is the diagnosis accurate: accidental complexity was introduced before the domain was understood, and it compounded for seven years.

So the rewrite reproduces the conditions that made the rewrite necessary. And in another seven to ten years, the conversation starts again.

A well-modeled system does not generate the rewrite conversation. Not because it is perfect, or because requirements don't change, or because technology doesn't evolve. But because the essential complexity — the domain model — is separable from the accidental concerns around it. Frameworks can be replaced without touching the domain. Infrastructure can evolve without restructuring the business logic. The system adapts because its core is stable, and its core is stable because it correctly reflects the domain rather than the technology choices of the year it was built.

The Ten-Year Cost Test can be applied to any system. And the rewrite conversation, or its absence, is the most honest result that test can produce.

The Uncomfortable Conclusion

The Singleton Paradox means the direct proof will always be unavailable. You cannot park the well-architected system next to the poorly-architected one and read off the difference, because only one of them was ever built. You cannot compare the fifteen-year maintenance cost of a domain-first system against a framework-first system because the framework-first system is the only one that exists.

What you can do is apply the Ten-Year Cost Test to what you have. Ask honestly whether maintenance is getting cheaper or more expensive. Whether new requirements are getting faster or slower to absorb. Whether the team is staying small or growing to manage complexity. Whether the system is getting more stable or less. Whether running costs are proportional to business growth or running ahead of it.

And ask whether the rewrite conversation has started.

The industry data — imprecise as it is, incomplete as it necessarily must be — points consistently in one direction. The average project fails all five dimensions of the test. Maintenance rises. Requirements slow. Teams grow. Stability declines. Costs outpace business value. The rewrite conversation starts around year seven and reproduces the conditions that made it necessary.

This has happened so consistently, for so long, that it has been normalised into invisibility. The inflated cost has become the reference point. The compounding expense of accidental complexity has become indistinguishable from the natural cost of building software — because no one in the room has ever seen it otherwise.

The proof that it can be otherwise exists — in systems maintained by small teams in complex domains, absorbing new requirements cleanly, costing the same to run as they did a decade ago. Those systems exist. They simply never get compared to the alternative, because the alternative was never built.

The absence of that proof in your organisation is not evidence that it is impossible.

It is evidence of the Singleton Paradox.

And the Singleton Paradox is not a law of nature.

It is a consequence of choices. But not random choices — choices made under a specific kind of pressure that has nothing to do with fit. Spring Boot is chosen because the last project used Spring Boot. CQRS is chosen because the architect gave a conference talk on CQRS. Event-driven architecture is chosen because it is what sophisticated teams are supposed to use. These are not engineering decisions. They are career decisions dressed as engineering decisions. No one got fired for choosing the framework everyone else is using. The choice is defensible precisely because it is popular — and because the Singleton Paradox ensures it will never be tested against the alternative, it remains defensible indefinitely, regardless of what it actually costs.

This is the root cause the industry rarely names. Not incompetence. Not malice. The systematic selection of solutions on the basis of social safety rather than demonstrated fit — in an environment where demonstrated fit is structurally impossible to measure.

Choices that can be made differently.

The Underestimated Power of Encapsulation in Software Engineering

Leon Pennings — Mon, 27 Apr 2026 08:46:44 +0000

Most Java developers today can explain encapsulation. They will tell you it means making fields private and adding getters and setters. They can recite SOLID principles on demand. They know the vocabulary.

What most of them have never experienced is what genuine object-oriented design actually feels like in practice — and that is the real problem.

Object-oriented principles did not disappear because of technology hype or the pace of change. They were never properly learned. A generation of developers was trained on frameworks, not on design. They learned Spring before they understood objects. They learned dependency injection before they understood responsibility. They learned how to make things work before they understood how to structure things well.

The result is an industry where object-oriented vocabulary is used to justify procedural habits. The Interface Segregation Principle — which is fundamentally about keeping responsibilities separate and coherent — gets applied as a rule for how to slice Spring interfaces. Encapsulation becomes a checkbox: private fields, public getters, done. The deeper meaning, and the profound practical value behind it, is lost entirely.

What dominates instead is procedural programming in disguise. Fat service classes orchestrate anemic data bags. Logic is scattered across layers. Objects exist to hold data, not to own behavior. The goal is implementation — make it work, ship it — not design. Not structure. Not a system that remains small, simple, robust, and maintainable as it grows.

This article is about what encapsulation actually means, what it actually does, and why practicing it properly changes both the software you build and the way you think about building it.

What Encapsulation Really Means

Encapsulation means that the "how" stays completely inside the object. Clients see only the "what" — the responsibilities the object fulfills. Nothing about implementation, nothing about mechanism, nothing about technology ever surfaces in the public interface.

Private fields are the minimum. The real discipline is in the public surface of the object. If a method exposes internal data, leaks a storage detail, or forces the caller to know anything about how the object works internally, encapsulation has already failed — regardless of whether the fields are private.

This extends to the constructor. A constructor that accepts implementation details — a storage mechanism, an external resource, a configurable strategy — is already exposing the "how." The object must own its implementation completely, from the moment it comes into existence.

A helpful guiding principle is "Tell, Don't Ask": tell the object what to do. Do not ask it for its data so that you can make decisions with it elsewhere. When you find yourself pulling data out of an object to decide what to do next, that decision almost certainly belongs inside the object itself.

The Cognitive Shift: From Technology to Responsibilities

Encapsulation is more than a coding rule. Practiced properly, it becomes a thinking tool that changes how you model systems from the ground up.

When you commit to hiding the "how," you are forced to think clearly about the "what." Technical questions — how do I store this, which framework handles this, which layer does this belong to — become the wrong questions. They are about implementation, and implementation is not your concern at this level. The right questions are: what is this object responsible for? What should it be able to do? Which other objects would it naturally talk to?

In a typical Spring application this shift never happens. Developers think in layers — controller, service, repository — and the central question is always "where does this code go?" That question produces a filing system for procedural code. It does not produce a domain model. The objects that emerge from it are empty by design, because the template has already decided that behavior lives in services, not in objects.

Asking "whose responsibility is this?" produces something entirely different: a coherent network of objects that each own their behavior completely, and that together tell the story of the domain.

Example: A Well-Encapsulated Document

Consider a compliance-heavy application where documents — PDFs, scanned forms, certificates — play a central role. They get created, stored, retrieved, and checked for compliance throughout the system.

The typical Spring-influenced approach treats Document as a data bag:

java

public class Document {
    private UUID id;
    private String filePath;    // leaks storage details
    private String mimeType;
    private byte[] content;     // exposes raw data

    public String getFilePath() { return filePath; }
    public void setFilePath(String path) { this.filePath = path; }
    public byte[] getContent() { return content; }
    // ... more getters and setters
}

This is not an object. It is a struct with ceremony. Every implementation detail is visible and reachable. Logic that belongs to the Document — storage, compliance checking, content retrieval — lives somewhere else, in a service class, spread across layers, written procedurally. Changing the storage mechanism means hunting through the entire codebase because the entire codebase is coupled to the implementation.

Now consider a Document that actually owns its responsibilities:

java

public class Document {
    private final UUID id;
    private final String name;
    private final String mimeType;

    public Document(String name, String mimeType, InputStream content) {
        this.id = UUID.randomUUID();
        this.name = name;
        this.mimeType = mimeType;
        // becoming a Document includes taking care of its own storage
        // the how is nobody else's business
    }

    public void writeToStream(OutputStream outputStream) {
        // retrieves and writes content — fully internal
        // the caller gets their bytes, nothing more
    }

    public boolean isCompliant() {
        // compliance logic lives here, where it belongs
    }

    public String getName() { return name; }
    public String getMimeType() { return mimeType; }
}

The Document figures out its own storage as part of coming into existence. It knows how to give its content back via writeToStream. It knows whether it is compliant. No file path is exposed. No byte array leaks out. No storage mechanism is visible to anything outside.

Usage across the system stays clean and expressive:

java

Document invoice = new Document("invoice.pdf", "application/pdf", contentStream);

transaction.attach(invoice);
invoice.writeToStream(responseStream);

Transaction knows it can attach a Document. It does not know — and has no reason to know — how the document stores itself, where it lives, or how it retrieves its content. The Document figures it out. That is the point.

Why This Matters at Scale

The benefits of this discipline are not always obvious on a small codebase. They become impossible to ignore as the system grows — and they show up most clearly when things need to change.

The core logic tells the story of the domain. When objects are modeled around responsibilities rather than technical concerns, reading the code means reading the domain. A Transaction attaches a Document. A Document knows whether it is compliant. The objects speak in business terms because they were designed in business terms. There is no framework noise, no layer indirection, no infrastructure vocabulary polluting the domain model. A new developer — or a returning one after six months — can understand what the system does by reading the objects, not by reverse-engineering a tangle of service classes and annotations.

Framework upgrades become a bounded problem. The dominant template in Java development today is well known: logic goes into services, data gets carried by DTOs, persistence is managed by repositories, and domain objects exist mainly to map to database tables. This pattern is taught as architecture. It is actually a prescription for hollowing out the domain. The objects end up empty. The behavior ends up scattered across service classes that have no natural boundary, no clear responsibility, and no reason to stay coherent as the system grows.

The consequence is that the framework and the domain become inseparable — not because of annotations on classes, but because the logic itself has been relocated into framework-managed components. Services are Spring beans. Transaction boundaries are framework concerns. The business reasoning is hosted inside the framework rather than sitting independently of it. When the framework changes, the logic has to move with it, because the logic lives inside it.

When domain objects genuinely own their responsibilities, this changes entirely. The core domain is a network of objects talking to each other in business terms, with no knowledge of the framework hosting them. The framework sits at the edges — handling HTTP, managing sessions, coordinating persistence — but it does not host the logic. Upgrading it, replacing it, or restructuring it becomes a bounded problem. The domain does not change because it was never coupled to the framework in the first place.

The five to seven year rebuild cycle is not inevitable. Most software organisations accept the full rewrite as a fact of life. After a few years, the codebase has become so entangled with its own technology choices that evolution is no longer possible — the only way forward is to start again. This cycle is expensive, disruptive, and demoralising. It is also, in large part, a consequence of building systems where business logic is hosted inside framework components rather than inside the domain itself.

When the core logic is a network of objects talking to each other in terms of responsibilities, it does not age the same way. The business rules, the domain relationships, the behavioural contracts between objects — these survive. Technology changes around them. The core endures.

Architectural evolution becomes manageable. Moving from a monolith to a distributed architecture, extracting a bounded context, splitting a service — these are genuinely difficult problems when business logic is woven through framework plumbing. When domain objects carry no framework baggage and communicate purely through their responsibilities, the same logic can move between architectural boundaries without fundamental redesign. The objects do not care whether they run in one process or ten. Their responsibilities do not change. Their interfaces do not change. The architecture is a deployment concern, not a domain concern.

The less the core depends on frameworks, the longer it survives. This is the underlying premise. Frameworks evolve, get replaced, fall out of favour, and eventually die. Business logic, when it is well modelled, does not have the same lifecycle. Keeping them genuinely separate — not just in theory, but in practice, through strict encapsulation — means the thing that actually matters, the domain model, accumulates value over time rather than accumulating debt.

Common Pitfalls

The data bag. A class whose primary purpose is to hold data with getters and setters is not an object in any meaningful sense. It is a data structure. Logic that should belong to it lives elsewhere, and that scattered logic is the source of most maintenance pain in large Java codebases.

The leaking constructor. A constructor that accepts implementation details — storage strategies, injected resources, configurable mechanisms — is already exposing the "how." This is dependency injection, and despite its near-universal adoption in Java development, it is a direct violation of encapsulation. The object should own its implementation fully. If it needs to talk to an external resource, it does so internally. That is not a variable, not a configuration point, not something the outside world participates in. It is simply what the object does. The widespread embrace of DI as a default pattern reflects an aversion to singletons and a desire for testability — both legitimate concerns — but it solves them at the cost of encapsulation, and that cost is rarely acknowledged.

Procedural code in disguise. A service class that takes data out of one object, makes decisions about it, and puts results into another object is a procedural function with a class wrapper. The behavior belongs in the objects themselves. The service class is a symptom of objects that do not own their responsibilities.

SOLID as a technical checklist. When principles like Interface Segregation or Single Responsibility are applied to framework configuration and layer boundaries rather than to object design, they produce architectural cargo cult — the appearance of structure without the substance. These principles are about responsibilities and design, not about how to wire up a Spring context.

A Note on Pragmatism

No codebase exists in a vacuum. Frameworks, ORMs, and serialization libraries are part of real-world development, and they sometimes need to know things about your domain objects. This is accidental complexity — the overhead introduced by the tools and environment you work in, as opposed to the essential complexity of the domain itself.

The key distinction is whether the accidental complexity adapts to the essential, or corrupts it.

JPA annotations on a domain object are a good example of acceptable accidental complexity. They decorate the object — they tell the framework how to map it — but they do not change what the object does, how it reasons, or how it protects its own state. The domain logic is untouched. If you removed JPA tomorrow, the object would still make complete sense. The essential complexity is intact. Accidental complexity that adapts to essential complexity without reshaping it is always acceptable — and recognising that distinction is itself a design skill.

The line is crossed when the framework starts dictating structure. A no-argument constructor that leaves the object in an invalid state. A setter that exists purely because the ORM needs to hydrate a field. A transaction boundary that forces business logic to be organised around framework sessions rather than domain responsibilities. At that point the accidental complexity is no longer adapting to the essential — it is reshaping it. The tool is now designing the domain, and the domain is losing its integrity.

The test is simple: if the accidental complexity were removed, would the core object still be coherent, valid, and complete on its own terms? If yes, the compromise is acceptable. If no, the framework has gone too far and the design needs to push back.

Conclusion: Encapsulation as a Force Multiplier

True encapsulation is strict. The object alone owns and hides everything about how it works. Clients see only responsibilities. The "how" is nobody else's business.

Practiced properly, it changes more than the code. It changes how you think about systems. You stop modeling data flow and start modeling behavior. You stop thinking in layers and start thinking in responsibilities. You stop asking "where does this code go?" and start asking "whose job is this?" The software becomes a network of objects that each know their job and do it — completely, independently, and without leaking their secrets.

That network survives in a way that layered, framework-dependent systems do not. It survives framework upgrades because the framework was never inside it. It survives architectural shifts because the objects carry no architectural assumptions. It survives time because it is organised around the domain — around what the software actually is — rather than around the technology that happens to be running it today.

Most Java developers today have never worked in a codebase built this way. That is not an accusation — it is a consequence of an industry that taught frameworks before it taught design. But it means that for many, genuinely object-oriented development would feel like a different discipline entirely.

It is. And it is worth learning.

Rich domain modelling: a library story

Leon Pennings — Sun, 19 Apr 2026 12:23:04 +0000

Most software doesn't have a domain model. It has a database schema, a set of service classes that orchestrate calls to it, and a collection of user stories that have been implemented one by one, each leaving a small deposit of logic somewhere convenient. This works, until it doesn't — until a framework needs replacing, a regulation changes, or someone asks a question the system was never quite designed to answer, and the answer turns out to be scattered across fourteen service methods and three database joins.

This article is about a different approach, illustrated through a deliberately simple example: a library system. The example is old-fashioned on purpose. The familiarity lets you focus on the reasoning, not the subject matter.

The core argument is this: a rich domain model is not something you design once at the start of a project and then implement. It is something you grow, continuously, as your understanding of the business deepens. Every requirement, every refinement session, every new user story is not just a work order — it is new information about the domain. The question to ask at each step is not "how do we implement this?" but "does this change what we understand the domain to be?"

If the answer is yes, the model changes. Not in a future story. Not as tech debt. Now. The implementation timeline is not sacred. The correctness of the domain is. The cost of a misaligned domain compounds over time — it gets into every new feature, every workaround, every "we can't easily change that" conversation. A missed sprint to correct the model is almost always cheaper than six months of working around a wrong abstraction.

The other side of this is: you only model what you understand. If something is unclear, that is not a reason to guess at an abstraction — it is a reason to ask more. Refinement sessions exist precisely for this. The domain expert knows things the model doesn't yet reflect. The job is to close that gap, incrementally, with each new piece of understanding.

That is what this article shows. Not a perfect model arrived at in one go, but a model that starts where the knowledge starts, and adapts as the knowledge grows.

User story 1: "We want to lend out books"

The first conversation with the domain expert goes predictably. The library wants to lend books. They want to know where each book is — on which shelf, or on loan to whom, from when until when.

From this, the initial domain objects emerge: Book, Lender, and somewhere, the loan dates. And this last point — where do the loan dates live? — is the first real decision.

The path of least resistance puts them in Book. The book knows where it is; if it's on loan, it knows to whom and for how long. It seems natural. But pause here, because this is the decision that will constrain everything that follows.

Ask a simple domain question: is knowing when it was borrowed, and by whom, part of what a book is? A book is a title, an author, a physical object. The loan is an event — an agreement between the library and a person, at a point in time, concerning that book. Two different things. Putting loan dates in Book is the same category of error as storing someone's employment history in their passport: adjacent subjects stitched together because it was convenient.

There is also a practical problem that makes the conceptual one concrete: a book can be borrowed many times, by different people, at different points in time. A single set of loan fields cannot represent that history without overwriting it. The model isn't just conceptually imprecise — it is structurally incapable of answering basic questions the business will eventually ask.

The first model, with its warning signs visible:

Recognising the problem, a Loan entity is introduced. It points to a book and a lender, and carries its own data: start date, end date, and a return date for when the item actually comes back.

Book is clean. Each entity is responsible for what it actually is.

Emergent behaviour: what the model now gives you for free

Here is something worth making explicit, because it tends to get overlooked.

When the domain is modelled correctly, it doesn't just solve the problem at hand — it makes available capabilities that nobody wrote a story for.

With Loan as a first-class entity, the model now contains the answers to questions like:

How many times has this book been borrowed in the last year?
Is it borrowed back-to-back — should we order a second copy?
Which items are overdue right now?
Which lender has the most active loans?

No one asked for any of this. And more importantly, no one needs to change the model to support it. These questions are answerable as a natural consequence of the right abstraction — zero additional structural cost. This is what correct domain modelling produces: not just a solution to the stated requirement, but a foundation that doesn't resist future questions.

The opposite — loan dates buried in Book — means that every one of those questions requires working around an accidental constraint. The data is there, technically, but it is in the wrong place conceptually, and that mismatch has a cost that accumulates with every new question the business wants to ask.

A correct abstraction doesn't just solve the current problem. It shapes every solution that follows.

User story 2: "We also want to lend out DVDs"

A new requirement arrives. The library wants to lend DVDs too.

On most teams, this is treated as a work order. There is now a DVD entity. Fields are defined — title, director, runtime. The ticket is closed.

This is precisely the failure mode the introduction described: a user story implemented rather than understood. The arrival of this requirement is not an instruction to add DVD. It is new information about the domain. And new information about the domain means it is time to re-examine the model.

The question is not "how do we add DVD?" The question is: was Book ever the right abstraction for this domain?

Think about what the lending system actually cares about. It doesn't care that a book has pages or that a DVD has a runtime. From the perspective of the lending domain, both are things that can be borrowed, returned, and tracked. If you add a DVD entity you are not modelling the lending domain — you are modelling a classification detail that the domain does not act on. And the next story will bring magazines. Then tools. Then a request that breaks the pattern entirely, and by then there are four parallel entity types, duplicated service logic, and a reporting layer full of unions.

The correct response to this user story is not implementation. It is evaluation. And the evaluation reveals that the concept the domain actually needs is not Book — it is a lendable item. Something that can be borrowed, regardless of what it is.

Modelling the domain, not the world

This is the point where a common objection appears: isn't LendableItem with a generic attribute collection just an EAV pattern with a different name? Isn't it losing type safety? Isn't it too abstract?

These are implementation concerns, not domain concerns. And that distinction matters enormously.

A book and a DVD are genuinely different things in the real world. They have different physical forms, different metadata, different cultural contexts. But the domain model is not a model of the real world. It is a model of how the business operates. And in the lending domain, a book and a DVD are the same thing: an item that can be lent to a person for a period of time, tracked, and returned. The domain acts on that concept. It does not act on the distinction between pages and runtime.

The risk in domain modelling is not abstraction. The risk is the wrong abstraction — and the most common wrong abstraction is modelling the real world instead of the business domain. When that happens, the model fills up with concepts that feel correct because they match physical reality, but that the business never actually operates on as distinct things. Book and DVD as separate domain entities is that mistake. The library doesn't lend books and DVDs differently. It lends items.

LendableItem is not generic for the sake of flexibility. It is precise — precisely what the domain requires.

This is not overengineering. Starting with Book was correct — at the time, only books existed, and naming the concept after the only known instance of it is entirely reasonable. Good domain modelling does not demand abstraction before there is evidence for it. But when the evidence arrives, the model must respond.

The revised model:

Book becomes LendableItem. The type — book, DVD, magazine, whatever comes next — is an ItemType instance defined in data, not in code. Each ItemType carries the attribute definitions relevant to it: a book has ISBN and author; a DVD has runtime and director. The LendableItem holds the attribute values as a key-value collection shaped by the ItemType — not arbitrary data, but controlled variation. A new lendable type can be defined through the UI, without a software release. The domain absorbs the variation without being touched.

Notice what also appears here: LendPolicy. Lending rules — how long something can be borrowed, whether it can be renewed — are not properties of items. They are policies, and policies have their own identity. A 7-day loan period might apply to all DVDs, a 21-day period to most books, and a specific rare edition might carry its own exception — all configurable, without code changes. By modelling LendPolicy as an entity that points to items rather than belonging to them, the granularity becomes a business decision. The domain reflects it correctly.

What this example is really about

Three things are worth naming directly.

The domain is not a one-off. The biggest misconception about domain modelling is that it happens at the start of a project, produces a diagram, and is then finished. In practice, a domain model is only as good as the understanding that produced it. Understanding grows — through refinement sessions, through new requirements, through conversations with domain experts who reveal nuance the model doesn't yet capture. Every one of those moments is an opportunity to improve the model. Treating them as implementation tickets instead is how misalignment accumulates.

Correctness compounds. A wrong abstraction doesn't just cause one problem. It causes every problem that grows on top of it. When the framework needs replacing five years from now, the core business logic should be the stable thing — the part that doesn't change because it correctly reflects the domain. If the logic has leaked into service methods, database queries, and framework-specific glue, the framework and the logic are inseparable. A rich domain model is what makes the core of the application resilient to the things around it changing.

User stories are input, not instructions. "We want to lend DVDs" is not a specification. It is a piece of information about the business. The correct response is to understand what it reveals about the domain, and let that understanding reshape the model if necessary. On teams where user stories are treated purely as work orders, DVD gets added, the ticket is closed, and the model silently drifts further from reality. On teams where user stories are treated as domain conversations, the arrival of DVD prompts the question that leads to LendableItem — and the system becomes more correct, not just more complete.

A note on SOLID

This article has used two principles from SOLID without naming them. It is worth naming them now — not to add jargon, but because these principles are widely known and almost as widely misunderstood, and the library example shows exactly what they were designed for.

SOLID is a tool for domain modelling. Applied to technical layers — controllers, services, repositories, packages — it is the wrong tool for the job. Not because it produces nothing useful there, but because it is answering questions that belong to a different space. Asking whether your BookService violates the Single Responsibility Principle is like applying flight-route optimisation to a city street map. You will get answers. They will be coherent. They will just not be answers to the right question. The right question is always about the domain.

When SOLID is applied only at the technical layer, the domain model is typically left untouched — a set of anemic objects with no real behaviour — while all the interesting decisions accumulate in a service class that nobody can coherently describe the responsibility of. The system is, in a narrow sense, well-structured. It models nothing.

The uncomfortable truth this produces is worth stating plainly: you can apply SOLID perfectly and still end up with a system that does not model the business. The principles do not tell you what to model. They evaluate whether what you have modelled makes sense. If what you have modelled is technical structure rather than domain concepts, SOLID will faithfully validate that structure — and the domain will remain a mess.

Applied to the domain, the principles are genuinely illuminating.

Single Responsibility Principle is what drove the Book → Book + Loan split. The question it asks is not "does this class do too many technical things?" It asks: does this concept carry responsibility that belongs to a different concept? A book is not responsible for knowing when it was borrowed. That is the responsibility of the loan event. One domain question, one correct answer, one new entity. Applied at the domain level, SRP produces clean, stable concepts with clear boundaries. Applied only at the technical level, it tends to produce BookHelper, BookManager, and BookUtil — classes that exist to split code rather than to model anything.

Open/Closed Principle is what drove the Book + DVD → LendableItem + ItemType move. The principle says a model should be open for extension but closed for modification. In domain terms: when new kinds of things appear, the model should absorb them without requiring existing concepts to change. A DVD entity requires a code change and a deployment every time a new item type is introduced. LendableItem with ItemType instances defined in data requires neither — the model is extended through configuration. The domain is open for new item types and closed against needing to touch LendableItem to accommodate them.

The remaining principles have domain equivalents too. But the point here is not to survey all five — it is to show that SOLID belongs in the domain conversation. Bringing it into the technical conversation is not a sequencing problem — it is a category problem. The principles ask domain questions. Technical layers are not a domain. The questions do not apply. It's like applying makeup to a horse. It works but the results have no benefit.

The model should always reflect the best current understanding of the domain. When that understanding changes, the model changes with it. Not later. Now.

Software Engineering Is Living The Golden Hammer Antipattern — And Everyone Loves It

Leon Pennings — Tue, 14 Apr 2026 05:25:25 +0000

Why the industry simultaneously agrees with Brooks and ignores him — and why it's structured to stay that way

The Paradox Nobody Talks About

Ask any experienced software engineer about essential versus accidental complexity. They will nod. Ask them about Brooks' central argument in No Silver Bullet — that the hard part of software is the conceptual work of understanding the problem, not the mechanical work of expressing it in code. They will nod again.

Then watch what happens when the next project starts.

Someone opens Spring Initializr. Someone proposes microservices. Someone puts Kubernetes in the architecture diagram before a single domain concept has been named. The technology stack is decided in the first week. The business domain is still being understood in month six.

Nobody in that room forgot Brooks. The choice was never really about Brooks.

That is the paradox this essay is about. Not that the industry is ignorant of the problem — but that it is structured to reproduce it perfectly, indefinitely, at enormous and invisible cost.

What Brooks Actually Said

In 1975, Frederick Brooks published The Mythical Man-Month, based on his experience managing the development of OS/360 at IBM. The project was late, over budget, and initially didn't work particularly well. Brooks spent the rest of his career trying to understand why.

The insight most people remember is the coordination problem. Adding people to a late software project makes it later. Nine women cannot make a baby in one month. Communication overhead scales quadratically. You cannot parallelise work that is fundamentally interdependent. Everyone knows this. It shows up in every post-mortem, every engineering blog, every conference talk about why the rewrite took three years instead of six months.

What people remember less clearly is the deeper argument Brooks made in his 1986 essay No Silver Bullet, later added to the anniversary edition of the book.

Brooks drew a distinction between two kinds of complexity in software. Essential complexity is inherent to the problem itself — the rules, the relationships, the invariants, the genuine difficulty of the business domain being modelled. Accidental complexity is everything else — the tools, the frameworks, the infrastructure, the deployment machinery, the coordination overhead introduced by the way we choose to build systems.

His claim was precise and devastating: there is no silver bullet because the hard part of software is essential complexity, and no tool or methodology can compress it. You cannot automate your way out of needing to understand the problem. You cannot framework your way past the conceptual work.

Then he said something that was either ignored or misunderstood: the industry's persistent belief that the next tool, the next methodology, the next architectural pattern will finally solve the problem of software difficulty is itself the symptom of failing to make this distinction.

That was 1986. Since then the industry has produced structured programming, object orientation, UML, SOA, agile, microservices, event-driven architecture, CQRS, cloud-native development, and AI-assisted coding.

Each one arrived as a silver bullet. Each one was greeted with the same enthusiasm. Each one was applied before the domain was understood.

Brooks' own framework predicted every step of it

The Golden Hammer The Industry Forgot To Question

There is a well-known antipattern in software called the golden hammer. It describes the tendency to over-apply a familiar tool regardless of whether it fits the problem. Named after Maslow's observation that if all you have is a hammer, everything looks like a nail.

The modern software industry does not have one golden hammer. It has a coordinated set of them — and they are chosen as a bundle, before the problem is understood, in almost every project that starts today.

The bundle looks like this: a popular framework for the application layer, microservices for decomposition, an event-driven or REST-based communication model, a cloud platform for deployment, and Kubernetes for orchestration. The specific tools vary by organisation and year. The pattern does not vary.

What makes this particular golden hammer different from the textbook antipattern is a crucial property: it is unfalsifiable.

A normal golden hammer eventually gets retired. Something demonstrates it was the wrong tool — the screw still won't turn, the nail bent, the joint failed. There is a moment of visible failure that creates pressure to reconsider.

The modern software stack has no such moment. If the system runs in production, the stack gets the credit. If the system struggles — if changes are expensive, if the team grows endlessly, if understanding the codebase requires months of archaeology — the blame goes to requirements changing, team turnover, business complexity, or simply the nature of software. The stack is never in the dock.

This is not an accident. It is a structural property of how software success is defined. A system running in production passes the only test anyone applies. There is no test for whether it could have been built at a fraction of the cost with a fraction of the complexity. Nobody built that version. Nobody ever does.

The golden hammer persists not because people are lazy or ignorant — but because the thing that should replace it is invisible to every organisational instrument the industry has built.

Agile Was The Correction. Then It Was Captured.

In 2001, the Agile Manifesto proposed something that was, underneath its somewhat vague language, a precise epistemological claim.

Software development is fundamentally a process of learning. You do not fully understand the domain at the start. You build a version of your understanding, expose it to reality — specifically to the domain experts who live in that business every day — and you refine it. Each iteration is not primarily a delivery mechanism. It is a question: did we understand the domain correctly?

The working software at the end of a sprint is not the point. It is the test. The test of whether your conceptual model of the business — your understanding of what the domain actually is, what rules govern it, what concepts belong together — corresponds to reality. Domain experts are not approving features. They are stress-testing your model.

That is what Agile was. A mechanism for continuously refining essential understanding through structured contact with reality.

That is not what Agile became.

What Agile became was a process for efficiently transcribing user stories into framework components. Two-week sprints. Velocity points. Definition of done. Backlog refinement. The ceremonies survived. The epistemology was quietly discarded.

And then CI/CD completed the transformation.

Continuous integration and continuous deployment are genuinely valuable practices for managing the operational complexity of releasing software. But they introduced a subtle and devastating redefinition of what "production ready" means.

Before, production readiness was at least nominally connected to domain correctness — does this system correctly implement the business? After, production readiness means the pipeline is green. Tests pass. Build succeeds. Deploy proceeds.

These are not the same question. A passing test suite validates that the code does what the code was written to do. It says nothing about whether the code was written to do the right thing. Whether the domain concepts are correctly identified. Whether the invariants are correctly enforced. Whether the model reflects the business reality or merely the user story that described one interaction with it.

You can have one hundred percent test coverage and zero domain correctness. The pipeline will be green. The system will go to production. The retrospective will be positive.

The feedback loop Agile promised — between domain experts and the conceptual model being built — was replaced by a feedback loop between the code and its own tests. We optimised the loop while removing the thing it was supposed to validate.

The Sociological Lock-In

So far this looks like an intellectual failure. Engineers and organisations that know better making choices they shouldn't. A problem of discipline or culture that better education might eventually correct.

It is not. It is structural. And the structure actively selects against correction.

Consider how a software project begins. Before a single domain conversation happens, several things must occur. The project must be staffed. That requires a job posting. A job posting requires a technology stack. The project must be estimated. Estimation requires a known architecture. The kickoff deck must be prepared. The kickoff deck needs something in the architecture diagram.

All of these organisational necessities demand a technology decision at the precise moment when the only intellectually honest answer is: we don't know yet. We haven't understood the domain.

That answer is organisationally impossible to give. So the stack gets chosen. Not out of ignorance. Not out of laziness. Out of genuine organisational necessity. The machinery of project initiation requires it.

And once the stack is chosen, it shapes everything that follows. The hiring criteria. The team composition. The onboarding process. The architecture decisions. The decomposition strategy. The system that emerges is not primarily a model of the business domain. It is primarily an expression of the technology choices made before the domain was understood.

This is not the worst part.

The worst part is what happens at the hiring stage.

Conceptual thinking — the ability to reason about what a business concept actually is, what it should own, what it should never be responsible for, where the real boundaries lie — is extremely difficult to assess in an interview. It requires time, domain context, and a level of conversation that most hiring processes cannot accommodate. It does not show up cleanly on a CV.

Tool fluency shows up immediately. Spring Boot, Kubernetes, Kafka, event-driven architecture — these are expressible, searchable, assessable. You can screen for them in thirty seconds. You can test them in a one-hour technical interview. You can verify them with a take-home assignment.

So organisations hire for tool fluency. Not because they don't value conceptual thinking. Because tool fluency is what their hiring process can see.

The consequence is a team that reaches for the familiar tools. The team ships systems using those tools. Those systems run in production. The hiring criteria get validated. The loop closes.

Engineers who push back on premature technology decisions get filtered out at the CV screen, outvoted in the kickoff meeting, or labelled as impractical idealists who don't understand how real projects work. The selection pressure is quiet, consistent, and almost entirely invisible.

When everyone hired thinks the same way, the golden hammer stops looking like a hammer. It looks like engineering.

The Cost Nobody Can See

Here is the claim that cannot be proven and cannot be dismissed.

A system built with a full modern distributed stack — framework, microservices, cloud infrastructure, orchestration — could in many cases have been built far more simply, maintained by a fraction of the team, and been more correct, more stable, and more responsive to business change.

That statement cannot be verified. Because the simpler version was never built. Nobody built it. The team that chose the distributed architecture never built the alternative to compare against. The organisation that approved the budget never saw a competing proposal. The engineers who maintained the system never worked on a well-modelled equivalent.

This is not a gap in the data. It is the mechanism of the problem.

Brooks identified it precisely: most systems are built only once. There is no second system built with different assumptions, run for five years, and compared on total cost of ownership, ease of change, and conceptual correctness. The counterfactual does not exist. Therefore the cost of the wrong choice is permanently invisible.

And here is what makes it truly unfalsifiable: the entire industry is paying the same inflated price. There is no reference point. When every team uses the same stack, incurs the same coordination overhead, grows to the same size, and struggles with the same maintenance costs — those costs stop being visible as costs. They become the definition of what software costs. Normal and wasteful become indistinguishable.

But the difference is not just in cost. It is in what the work actually consists of every single day.

In a team organised around accidental complexity, the daily work is about the technology. Configuring services. Connecting components. Managing framework upgrades. Fixing pipeline failures. Debugging integration issues. Updating dependencies. Understanding the codebase means knowing which service owns which endpoint and how the data flows between them. The business domain is somewhere in there, translated into controllers and DTOs and event schemas, but it is not what the day is about.

In a team organised around essential complexity, the daily work is about the domain. Which concept owns this responsibility. What this rule actually means. What the domain expert said yesterday that changed how they understand the model. The implementation follows from that understanding — and because the model is clear, the implementation is the smaller part of the day, not the larger.

The difference is visible — immediately and without any instrumentation — in the daily standup.

In one team, the language is technical. Spring, Kafka, the pipeline, the service, the endpoint, the migration. Progress is reported in terms of tickets and story completion. The word "business" appears occasionally, usually in the phrase "business requirement."

In the other team, the language is conceptual. The Order, the Invoice, the Payment, what a Shipment is responsible for, whether a Client and a User are really the same thing. Technology appears occasionally, usually briefly, because the implementation of a well-understood concept is rarely the hard part.

You do not need metrics or cost analyses to know which team is working on the right problems. You need one standup.

If every item on the standup is about accidental complexity — go back. Ask what the essential complexity actually demands. Then and only then choose the technology that serves it.

If every garage in the world were built to the standard of a luxury hotel, nobody would know a garage could cost less. The price would simply be what it is. The inflated standard would be the only standard anyone had ever seen.

That is where the software industry is today. Paying Burj Al Arab prices for a garage that needed to store a jar of paint. And maintaining a universal, genuine, unforced consensus that this is simply what garages cost.

Two Rules That Cost Nothing

Most prescriptions for this problem are expensive. Hire differently. Retrain your engineers. Adopt a new methodology. Bring in consultants. Run workshops.

These are not wrong. But they require budget, time, and organisational will that most teams do not have in the moment a project starts.

There are two rules that cost nothing, require no external help, and can be applied starting tomorrow.

Do not choose technology upfront.

Technology enters the project when the domain demands it, not when the kickoff deck needs an architecture diagram. The first weeks of a project produce domain understanding — what the business actually is, what concepts exist in it, what rules govern them. Technology choices follow from that understanding, added only when essential complexity makes them necessary, and only to the degree that it does.

This feels impossible in most organisations. The job posting needs a stack. The estimate needs an architecture. The kickoff slide needs something in the boxes.

Those are real constraints. They are also exactly the organisational machinery that inverts Brooks before the first line of code is written. Recognising that the machinery is the problem is the first step toward not letting it make the decision by default.

Mandate that standups should be about business concepts only. Never technology.

This is the litmus test made into a practice. If someone says "I'm working on the Kafka consumer," the immediate question is: what business concept does that serve, and does that business concept actually require it? If the answer is unclear, the technology choice is premature. If the answer is clear, state the business concept first and let the technology be the footnote it should be.

A standup where every item is about services, frameworks, pipelines, and endpoints is a standup where the team has been captured by accidental complexity. It will feel entirely normal. It will sound like engineering. The terminology will be confident and precise.

But the business domain — the essential complexity that justifies the system's existence — will be invisible. And a team that cannot talk about the business in its daily standup is a team that is not working on the business. It is working on the technology that was supposed to serve it.

These two rules do not solve the problem entirely. The sociological pressures remain. The hiring pipelines remain. The organisational machinery remains. But they create two moments — one at the start of a project, one every single day — where the inversion becomes visible. Where someone can point at the standup and say: we have not mentioned a business concept in three days. What are we actually building?

That question, asked consistently, is more powerful than any methodology.

Closing

The most expensive software is the software everyone agrees is fine.

It runs in production. The pipeline is green. The team is stable. The architecture is recognisable. The job postings write themselves. The onboarding takes three months instead of three days, but that is just how software works. The changes take longer than they should, but the domain is complex. The team keeps growing, but the system keeps growing too. The costs keep rising, but software is expensive.

None of this is inevitable. All of it is a consequence of a single inversion: accidental complexity chosen before essential complexity is understood. A choice made not out of ignorance, but out of organisational necessity, sociological pressure, and the permanent invisibility of the alternative.

Brooks saw it in 1975. Named it clearly. Watched the industry quote him extensively and change nothing.

The golden hammer is not a mistake. It is the product. The template is not a shortcut. It is the destination. The assembly is not the means. It has become the craft.

Two rules. No technology upfront. Standups about the business only.

They will feel radical. They are just Brooks, applied.

Everyone agrees with Brooks.

Then the next project starts.

Fast Onboarding of Software Engineers: The Two Learning Modes

Leon Pennings — Fri, 10 Apr 2026 11:43:42 +0000

There is a persistent belief in software organizations that standardizing on a single framework — Spring Boot being the popular example — makes developers interchangeable across teams. If every system is built the same way, engineers can move between projects with minimal friction.

It sounds efficient. It feels scalable. It is also largely wrong — and understanding why reveals something important about how developers actually learn.

Two Ways to Learn a Codebase

There are fundamentally two modes through which a developer can come to understand a system.

The first is comprehension-based learning. The developer is walked through the core domain concepts — typically in a whiteboard session — and can then trace those exact concepts in the code. The system is legible. Understanding precedes execution.

The second is execution-based learning. The developer runs the system, breaks it, watches it, traces calls through layers. Understanding is assembled gradually from observed behavior. This is the default mode for procedural and layered architectures.

The practical consequence of this difference is not marginal. Comprehension-based onboarding can bring a developer to effective contribution within hours to days. Execution-based onboarding routinely takes weeks to months before a developer can contribute without close supervision.

That gap is not a matter of individual ability. It is a structural property of the codebase.

Pair programming, shadowing, and extensive debugging sessions are not learning strategies in this context. They are compensations — workarounds for the absence of anything readable at the conceptual level. Organizations that rely on them have simply normalized the cost of an illegible system.

Framework standardization does nothing to change this. Recognizing a controller is not the same as understanding why the endpoint exists, what constraints govern it, or what invariants must never be broken. That knowledge lives in the domain — and in most codebases, it lives nowhere at all.

What Comprehension-Based Onboarding Actually Looks Like

In a well-crafted domain model, onboarding follows a different rhythm entirely.

A developer new to the system joins a whiteboard session — 30 to 60 minutes — where the core domain concepts are walked through. They then open the codebase and can trace those exact concepts in the code. Within an hour, the relationships between concepts — what governs what, what depends on what, what is allowed and what is forbidden — form a coherent picture. By the end of the first day, they can participate meaningfully in design discussions, and in many cases begin implementing new functionality.

This is not aspirational. It is the direct consequence of a system that makes its intent legible.

The critical insight is this: new functionality must be grounded in what a system does, not in how it is written. A developer who understands the domain can reason about where new behavior belongs, what rules it must respect, and how it connects to existing concepts — without having traced a single execution path. That is what makes hours-to-days contribution possible. Without it, the developer has no foundation to build from, and execution-based exploration begins — with all the time cost that entails.

First Principles, Not Seniority

This is not about experience level. A junior developer who thinks from first principles — who reasons about what a system is and what it must never do before asking how it runs — will orient just as quickly as a senior. First-principles thinking is a mode, not a career stage. It is the ability to think and talk in concepts and responsibilities, to ask the right questions before reaching for the debugger.

Execution-based systems actively disadvantage this kind of thinking. There is nothing to reason from. The only available strategy is empirical — run it, break it, observe. That favors pattern recognition over understanding, and accumulated exposure over insight. It rewards engineers who are good at navigating complexity rather than those who are good at resolving it.

Over time this has consequences beyond onboarding. The system comes to be understood only by those who have been exposed to it long enough — and institutional knowledge becomes a function of tenure rather than clarity.

Why Most Systems Make This Impossible

The root causes of slow onboarding are almost never the framework. They are structural.

Implicit domain knowledge. Critical business rules are undocumented and embedded in conditionals, naming conventions, and historical decisions nobody questions anymore. New engineers are forced into archaeology before they can contribute. Every answer is buried somewhere in the execution history.

Fragmented business logic. When behavior is spread across controllers, services, and repositories, there is no single place to understand what the system enforces. Every answer requires assembling fragments from multiple layers — which means execution-based exploration is the only path available, regardless of how familiar the framework feels.

Workflow-centric design. Systems modeled around flows — requests, events, pipelines — force developers to reconstruct intent from execution paths. The what is buried inside the how. Reading the code tells you what happens; it does not tell you why, or what must never happen.

These are not framework problems. A Spring Boot application can have a rich domain model. It rarely does, because framework-driven thinking optimizes for how we build rather than what we model — and that trade-off silently pushes onboarding from days into months.

The Domain Model as a Table of Context

A well-structured domain model acts as a compression mechanism for complexity. Core concepts are named clearly. Invariants are enforced in one place. Relationships are explicit.

This gives the codebase something more useful than a table of contents. It provides a table of context: each concept is not just listed but anchored in meaning and relationship. A new developer does not navigate files — they navigate intent. And navigating intent is something a first-principles thinker can do quickly, regardless of how many years they have been writing code.

For this to work, the code must speak the language of the business. If stakeholders say DocumentRequest, the code should not say PayloadDTO. When the language of the domain is reflected faithfully in the implementation, onboarding becomes a translation exercise rather than a decoding one. Translation is fast. Decoding is slow.

A Useful Side Effect: Simpler Code

Systems with rich domain models tend to produce surprisingly simple implementations. This is not accidental.

When complexity is resolved at the conceptual level — when the model clearly captures what is allowed, what is forbidden, and where behavior belongs — it does not accumulate elsewhere. There is less need for elaborate orchestration, framework configuration, or infrastructure glue.

In contrast, systems that lack a strong domain model push complexity into the gaps: coordination logic spreads across components, edge cases get patched rather than modeled, and understanding the system requires tracing runtime behavior rather than reading domain logic. Infrastructure complexity grows not because it is necessary but because the domain complexity has nowhere else to go. This is precisely what makes execution-based onboarding so expensive — the system keeps revealing new layers of implicit complexity the longer you look.

The Role of Frameworks, Properly Understood

Frameworks are not without value in onboarding. They reduce setup friction, provide familiar scaffolding, and standardize infrastructure concerns. A developer who knows Spring Boot will navigate a Spring Boot project faster than a complete stranger would.

But this is surface-layer familiarity. It accelerates the first few hours. It does not touch the weeks that follow.

Onboarding has two layers:

Surface layer — framework, build tools, deployment setup, API conventions. Fast to learn, low in durable value. Framework standardization helps here.

Deep layer — domain concepts, object responsibilities, business rules, architectural boundaries. This is where the weeks-to-months cost lives. Framework standardization does nothing here.

Most organizations optimize the surface layer because it is visible and measurable. They neglect the deep layer, absorb the onboarding cost as a fact of life, and attribute slow ramp-up to individual developers rather than to the structure of their systems.

Conclusion

The question of onboarding speed is ultimately a question of legibility.

A codebase with a well-crafted domain model is legible. A single whiteboard session on the core concepts is enough to orient a developer — because when they open the codebase, those exact concepts are right there, named and structured as explained. The session and the code reinforce each other. From that foundation, a first-principles thinker — junior or senior — can form a complete picture and begin making meaningful contributions within hours to days.

A codebase without one is an execution environment. You learn it by running it, breaking it, and asking the person who wrote it. That process takes weeks. Often months. And it repeats itself every time a new engineer joins.

If you want engineers to move between projects effectively, do not standardize the tools. The tools are not the barrier.

Standardize the clarity of the domain. Make systems understandable rather than developers interchangeable.

That is the real multiplier.

When Distribution Becomes a Substitute for Design — and Fails

Leon Pennings — Tue, 07 Apr 2026 08:41:51 +0000

A lot of modern software architecture—microservices, event-driven systems, CQRS—is not born from deeply understanding the domain. It is what teams reach for when the existing application has become a mess: nobody really knows what’s happening where anymore, behavior is unpredictable, and making changes feels risky and expensive. Instead of asking “What does this concept actually mean and where does it truly belong?”, they ask “How do we split this?”

That is where a lot of modern architecture begins.

Not in necessity.

Not in insight.

But in the growing discomfort of trying to manage software that was never modeled well in the first place.

And because the resulting system still runs in production, the cost of that move often remains invisible for years.

That is one of the most expensive traps in software.

Framework Fluency Is Not Software Design

A lot of developers today are highly fluent in frameworks.

They know how to build controllers, services, repositories, DTOs, entities, integrations, and configuration.

From the outside, that often looks like competence.

But that kind of fluency can be deeply misleading.

Because building software out of familiar framework-shaped parts is not the same thing as designing software well.

The real questions are different:

What is the actual business concept here?
What belongs together?
What behavior is intrinsic to the domain?
What is a real boundary, and what is just an implementation detail?
What rules should be explicit in the model rather than implied by orchestration?

Real domain modeling is not about applying a catalog of patterns. It is the disciplined, often uncomfortable work of discovering what belongs together, what behavior is intrinsic, and expressing those concepts as clearly and cohesively as possible—whether that lives in modules, functions, or simple objects. The goal is conceptual integrity, not architectural ceremony.

Without those questions, software tends to take on a very predictable shape: fat service classes, anemic entities, persistence-first design, procedural workflows, business logic smeared across layers.

The code works. The endpoints return data. The database persists state.

But the system has not really been designed.

It has been assembled.

And that difference matters far more than most teams realize.

Weak Models Create Cognitive Overload

The cost of poor design does not usually show up immediately. At first, the system still feels manageable. A few controllers. A few services. A few repositories. Everything is still “clean.”

But over time, something starts to happen. Business rules accumulate. Exceptions pile up. New requirements interact with old assumptions. Concepts that looked simple turn out to be related in ways the software never captured.

And because there is no strong domain model holding those concepts together, the complexity has nowhere coherent to go. So it leaks—into service methods, orchestration flows, integration glue, persistence logic, special-case conditionals, “helper” abstractions, and coordination code.

At that point, the team starts feeling something very real:

Nobody understands the whole thing anymore.

And that is the crucial moment.

Because once a system becomes cognitively overwhelming, the team has two options:

Option A

Reduce the complexity by improving the model.

Option B

Reduce the scope of the confusion by splitting it apart.

A lot of teams choose Option B.

Distribution Becomes Compensation

This is where architecture often stops being a design choice and starts becoming a coping mechanism.

When the internal model is weak, teams still need some way to create order. And distribution gives them one.

So they introduce microservices, event-driven architecture, CQRS, separate read models, ownership boundaries, queues, and asynchronous coordination.

Distribution, CQRS, and event-driven architecture can have legitimate uses in rare cases of extreme scale or unavoidable organizational boundaries. But in the vast majority of systems, they are not introduced because the domain demands them. They are introduced because the internal model is too weak to provide clarity. What looks like sophisticated architecture is often just confusion hiding behind cleaner service boundaries.

What they are really doing is this:

They are trying to create externally, through distribution, the boundaries they failed to create internally, through design.

And that can work. At least for a while.

A smaller service does feel easier to understand than a large monolith. A separate read model does reduce some friction. A queue does create some local decoupling.

But none of that means the software has become conceptually better. It often just means the confusion has been sliced into smaller containers.

Local Clarity Comes at a Global Cost

That trade is where the real damage happens.

Because distribution absolutely can create local context. A team can say, “This service owns billing.” And that does help.

But it is a much weaker form of clarity than a real domain model. A service boundary can tell you where code lives. A good model can tell you what something is, what it means, what rules govern it, what its lifecycle is, and what relationships are essential.

Those are very different levels of understanding.

And when teams use distribution to manufacture context, they often gain short-term manageability at the cost of long-term agility. Because now the system starts paying the distribution tax: network failure, eventual consistency, contract drift, duplicated concepts, duplicated logic, coordination overhead, deployment complexity, operational burden, and fractured causality.

And perhaps most importantly: lost refactorability.

When the model is strong and cohesive, changing your mind usually means a local refactor—sometimes even a delightful collapse of concepts. When boundaries have been hardened into services, the same insight triggers contracts, versioning, migration scripts, and cross-team coordination. The cost of learning is no longer paid in thought, but in infrastructure and politics.

And in software, changing your mind is not a failure. It is the job.

The Real Cost Is Paid When the Business Learns Something New

This is where badly structured software reveals itself. Not when it is first deployed. Not when the first endpoints work. Not when the dashboards are green. But when the business itself becomes better understood.

Because that is what always happens. Sooner or later, the business learns: these two concepts are actually one thing, this workflow was modeled incorrectly, this rule has important exceptions, this distinction is more important than we thought, or this process should not exist at all.

That is normal. That is what software is supposed to accommodate.

A coherent domain model makes that kind of change survivable. A fragmented, distributed, weakly modeled system makes it expensive.

Note that “coherent domain model” here does not mean the tactical patterns that became associated with DDD—entities, repositories, aggregates, and the rest. Those often added their own accidental complexity. Real modeling is simpler and deeper: it is the ongoing work of refining ubiquitous language and discovering natural conceptual boundaries so that new business insight can be absorbed with minimal violence to the existing code.

Because now the insight has to travel through APIs, queues, read models, event contracts, deployment boundaries, ownership lines, duplicated rules, and partial consistency guarantees. What should have been a conceptual refactor becomes a cross-system negotiation.

And that is where the bill arrives. Not because the domain was inherently impossible. But because the architecture froze yesterday’s misunderstandings into today’s structure.

That is one of the worst things software can do.

Why This So Often Goes Unnoticed

The most dangerous part is that this kind of architecture often looks successful. The system runs. Users use it. The company makes money. So the architecture gets treated as validated.

But “it works” is one of the weakest standards in software. A system running in production proves only that it is viable enough to survive. It does not prove that it is cheap to change, conceptually sound, structurally coherent, or good at absorbing new understanding.

Most teams never get to experience how different software feels when:

Concepts have a single, obvious home instead of being smeared across services
Rules are explicit and enforceable rather than scattered in orchestration and glue code
New business understanding leads to a clean refactor instead of distributed coordination
The system invites insight instead of resisting change

Without that contrast, the pain of weak modeling hidden behind distribution gets normalized as “just how complex software is.”

Often, it is not. Often, it is just the cost of weak design hidden behind architecture.

Final Thought

Much of today’s distributed architecture is not the result of domain insight. It is compensation for the conceptual clarity that was never built into the model. By reaching for separation instead of deeper understanding, teams gain local manageability at the expense of long-term coherence and cheap evolution.

The problem is that the original lack of clarity doesn’t disappear — it just gets distributed. In the end, the same confusion that made the monolith unmaintainable will make the distributed system fail just as hard, only now it’s far more expensive and painful to fix.

This is why so much “sophisticated” architecture is, in truth, just sophisticated coping.

Rich Domain Models: Start with What Is, Not What Happens

Leon Pennings — Sat, 04 Apr 2026 10:18:12 +0000

A lot of software is more difficult to build and maintain than it needs to be.

Not because the business itself is inherently complex.

Not because the requirements keep changing.

But because the software is usually structured around the wrong things: workflows, events, commands, technical layers, frameworks, or current implementation details.

When that happens, the business logic becomes scattered, hard to reason about, and expensive to evolve. The fix is not more patterns, more ceremonies, or more events. The fix is proper domain modelling.

A rich domain model is built by first identifying the core concepts of the business and giving each one clear responsibilities and boundaries. Once that foundation is in place, everything else—events, workflows, persistence, integrations—becomes simpler and more stable.

This is not a new technique or a branded method. It is basic systems engineering done in the right order.

The purpose of domain modelling

Domain modelling is about discovering what exists in the business, independent of how we happen to implement it today.

It means answering a small set of fundamental questions for every important concept:

What is this thing?
What is it responsible for?
What may it know?
What may it decide?
What belongs inside its boundary, and what does not?

These questions come before any talk of events, commands, database tables, API payloads, or user flows. If those questions have not been asked and answered, domain modelling has not actually started. At best, we are only mapping interactions.

Start with responsibilities, not representation

The most common mistake is beginning with representation instead of responsibility.

Teams start listing fields, DTOs, JSON shapes, database columns, or REST endpoints. Those are not the model; they are merely one possible way to represent the model. When you start there, you almost always end up with passive data structures and procedural logic spread across services, handlers, and utility classes.

A rich domain model begins the other way around. The first questions are never “What properties does this object have?” or “What does the request body look like?” They are:

What is this thing?
What does it do?
What is it responsible for?
What should it never be responsible for?

Structure and representation emerge naturally once responsibilities are clear.

A simple way to begin

You do not need extensive workshops, coloured sticky notes, or elaborate frameworks.

The most effective technique is almost embarrassingly simple: put people in a circle of chairs. Tell one person, “You are the Order. What are you? What do you know? What are you responsible for? What should you never do?” Then add the next concept—Client, Invoice, Payment—and let them talk to each other. Let them negotiate boundaries. When something feels wrong, revise the definitions or pull up a new chair for a missing concept.

The medium does not matter—cards, people, puppets, or just conversation. What matters is that you can point at a concept and force it to declare its own identity and responsibilities. When two concepts constantly need to know each other’s internals, the boundaries are probably wrong. When no one knows who should decide something, the responsibility has not been assigned yet. When a concept only exists because a UI flow needed it, it may not be a real domain concept at all.

This is domain discovery. It starts with “What are we about?” and then “Who does what?”—not in the sense of users or actors, but in the sense of the actual participants in the business reality: Client, Order, Invoice, Payment, Subscription, Shipment, Notification.

Why starting with events or workflows feels backwards

Many popular modelling techniques (Event Storming being the most visible) begin with domain events, commands, actors, and processes. They are excellent at mapping what happens and at surfacing integration points. But they are weak at discovering what is.

They describe motion around the business rather than the business itself. A process map can tell you that a payment failed. It cannot tell you what a Payment is, what responsibilities it owns, or whether Invoice resolution belongs to the Invoice, the Order, or a separate Payment concept. It cannot distinguish a Client (the legal/commercial entity) from a User (merely a web-access mechanism for that Client).

Those are modelling questions, and they must come first. Events and workflows are valuable after the core model exists; they should not be the starting point. Otherwise the domain becomes limited to today’s usage patterns instead of reflecting the stable underlying reality.

Aggregates and the danger of procedural models

The concept of “Aggregate” is often presented as a necessary consistency boundary. In practice it frequently becomes a procedural container: a cluster of data that a command mutates and an event is emitted from. When responsibilities have not been properly assigned, those aggregates turn into little more than transaction scripts with a fancy name.

In a rich model the question is simpler: does this concept have a coherent responsibility? If it does, it owns its invariants and decisions. If it does not, no artificial boundary will save it. Objects can collaborate, but they do not need to be artificially clustered just to satisfy technical consistency rules.

Rich domain models make the core simple

A well-defined domain model does not add complexity; it removes accidental complexity.

Consider a typical payment flow. An Order contains Items. An Invoice points to an Order. An Invoice can be resolved by a Payment. A Payment has a type (Online, BankTransfer, etc.). That type determines how execution actually happens.

In a responsibility-driven model this is straightforward:

The Invoice knows it needs to be resolved.
The Payment knows it must execute according to its type.
The type itself (implemented as an enum with a strategy or small implementing classes) encapsulates the variability.

Adding a new payment mechanism tomorrow is a local change inside the Payment concept. No new workshop, no new event storm, no ripple through services. The core model stays stable; only the variable part grows.

Complexity lives exactly where the variability is—not scattered across workflows, services, or “process managers.”

Keep the domain central; push technology to the border

The real architectural decision is not whether a domain object may call a database or invoke an external service. The question is: does this action belong to the responsibility of this concept?

If the answer is yes, the call can live inside the domain object. Technology is not the organising principle. The business meaning is.

When you organise around technology layers instead (controllers, services, repositories, adapters), the business becomes invisible. Every change requires archaeological digging. When you organise around the domain, the business stays transparent and technology becomes replaceable.

Outcomes — short term and long term

A domain model built this way delivers measurable improvements from the very first delivery and compounds dramatically over time.

Short term: Time to first production is usually shorter, not longer. With a rich domain model you know the destination clearly from the start, so you can take the direct route. It is the difference between driving from The Hague to Utrecht on the A12 motorway versus taking the long detour via Amsterdam and the Afsluitdijk. Both paths eventually get you there, but the workflow-first approach feels like continuously driving “somewhat in the right direction” while you figure things out on the fly. By modelling what the business is, you learn faster, decide faster, write less boilerplate, and avoid the lengthy refactoring cycles that come from discovering the business domain later in the project.

Long term: The difference becomes stark — especially in non-CRUD domains such as complex ETL pipelines, logistics orchestration, risk engines, or any system with real business rules and variability.

The “framework-first” or “workflow-first” approach can appear to work for a while. You can wire together services, handlers, and event processors and ship something functional. But as soon as the business evolves — new payment types, new regulatory rules, new integration partners, or changed data flows — the system turns into a web of scattered logic. Maintenance becomes slow, error-prone, and expensive. Changes ripple unpredictably because the business is no longer visible in one coherent place.

In contrast, a rich domain model keeps the stable business reality in the centre. Change stays local. Payment providers, ETL transformations, or logistics carriers can be swapped without touching the core model. Fewer classes, fewer hand-offs, and far less rediscovery work are required. The result is software that is significantly cheaper to keep alive over its lifetime — often by a large margin.

The economic benefit is real, but it is not the goal. It is the natural outcome of doing the engineering work correctly: modelling the domain first, responsibilities first, structure first.

On AI and domain modelling

Modern AI tools are already excellent at helping with the implementation phase. They can generate clean code snippets, suggest conventions, enforce patterns, and accelerate boilerplate work once the model is clear.

But they have no meaningful role in the actual domain modelling itself.

AI cannot sit in the circle of chairs. It cannot negotiate what a concept is, what it should know, or what it should never be responsible for. It can mimic patterns it has seen in other codebases, but it lacks the lived understanding of business reality and the ability to discover stable invariants through dialogue.

Writing the code remains the best mirror for your design. As soon as you start implementing, flaws in the model become visible immediately — that feedback loop is irreplaceable and deeply human. AI can polish and speed up the coding, but it should not be the one discovering or deciding the model. That work still belongs to the people who understand the domain.

Final thought

Basic domain modelling is not complicated. It is simply insisting on answering the most fundamental questions first:

What is this thing?
What is it responsible for?
What belongs inside it?
What should remain outside it?

When those questions are answered clearly, the business becomes visible in the code. Once the business is visible, the system becomes maintainable — from day one and for years to come.

That is not a luxury. For any software expected to live longer than its current tech stack, it is the foundation.

Your software development approach is too expensive and too brittle

Leon Pennings — Thu, 02 Apr 2026 08:14:22 +0000

Most software teams are not struggling because software is inherently chaotic.

They are struggling because they are paying enormous amounts of money to keep the wrong machine barely usable.

That sounds dramatic.

It is not.

In fact, it is one of the most normal things in modern software development.

A lot of systems are built in ways that are:

more expensive than they need to be,
more fragile than they need to be,
harder to change than they need to be,
and harder to reason about than they need to be.

And yet they still get called “well architected.”

Why?

Because in software, there is usually no comparison case.

No control group.

No alternate implementation.

No tractor parked next to the Ferrari.

So if the thing eventually works, the architecture often gets promoted from merely functional to supposedly good.

That is one of the deepest blind spots in software engineering.

And it is how teams end up trying to plow fields with a Ferrari F40.

The Ferrari and the tractor

Imagine you need to plow a field.

You can choose between:

a Ferrari F40, or
a tractor.

This should not be a difficult decision.

The tractor is not glamorous, but it is aligned to the work.

It has:

the right ground clearance,
the right tires,
the right torque profile,
the right durability characteristics,
the right maintenance expectations,
and the right operational shape.

The Ferrari has none of that.

It is a remarkable machine.

It is just the wrong one.

And the mismatch does not merely show up once the work starts.

It shows up immediately.

Because before the Ferrari can even begin to perform badly in the field, someone first has to solve a completely absurd problem:

How do we even make this thing usable for field work?

That is where the real cost begins.

Because now you need compensations.

You need:

custom adaptations,
support structures,
protective workarounds,
non-native operational handling,
specialist maintenance,
and constant care to keep the machine functioning in an environment it was never shaped for.

That is the real problem with a mismatch.

Not just that it performs badly.

But that you now have to build an entire support ecosystem around the fact that it is wrong.

And even that is a cheap mismatch compared to software

In the physical world, the mismatch would at least be visible.

A Ferrari F40 is obviously a terrible agricultural investment.

Even with rough but realistic assumptions, the economics are absurd.

In the physical world, the absurdity would be obvious on a balance sheet. A collector Ferrari F40 trades for millions, while a capable farm tractor costs a fraction of that — with maintenance profiles to match. Using the supercar for field work would not just perform poorly; it would demand absurd custom adaptations before it could even start.

Software hides this mismatch better, which is why teams can run the equivalent for years and still call it maturity.

So yes: in the real world, using a Ferrari to plow a field would already be economically insane.

But in software, the mismatch is often much worse.

Because in software:

the cost is less visible,
the pain is spread over time,
the friction is normalized,
and the organization often has no simpler implementation to compare it to.

That means software teams can spend years operating the equivalent of a Ferrari in a muddy field and still call it “engineering maturity.”

That is the danger.

The uniqueness trap

This is one of the hardest structural problems in software development:

most applications are built only once.

Not once in terms of business purpose, perhaps.

But once in terms of implementation.

A team typically does not build:

one version with a cohesive domain model,
another with CQRS and event choreography,
another with five microservices,

and then compare cost, reliability, comprehensibility, and adaptability over five years.

That almost never happens.

So architecture is rarely judged comparatively.

It is judged internally.

And that means if a system eventually “works,” people often conclude that the architecture must have been reasonable.

But that conclusion is deeply unreliable.

Because there may have been a far cheaper, simpler, more robust, and more truthful way to build the same thing.

No one knows.

Because the tractor version was never built.

That is the uniqueness trap.

And it is one of the main reasons accidental complexity survives so easily in software.

Most software architecture is expensive support structure around a mismatch

This is where the Ferrari metaphor becomes useful.

If someone insisted on plowing a field with an F40, they would not simply “start plowing.”

They would first need to invent a whole support system around the mismatch.

They would need to answer questions like:

How do we prevent the chassis from bottoming out?
How do we maintain traction in mud?
How do we protect components from wear profiles they were never designed for?
How do we attach the wrong machine to the wrong task?
How do we keep it alive under repeated misuse?

In other words:

they would need to build a compensating architecture around the fact that the machine is wrong.

That is exactly what many software teams do.

They choose an architectural shape before they understand the domain, and then spend years building support mechanisms around the mismatch.

That support structure often looks like:

CQRS,
EDA,
orchestration layers,
distributed workflows,
microservices,
command buses,
event buses,
retries,
compensations,
synchronization logic,
observability scaffolding,
deployment choreography,
and framework conventions.

And because all of this is technical work, it often feels sophisticated.

But much of it exists only because the software was shaped incorrectly to begin with.

That is the setup tax of accidental complexity.

Back to Brooks: essential versus accidental complexity

Fred Brooks gave us the cleanest possible vocabulary for this problem decades ago.

Essential complexity

Essential complexity is the irreducible complexity of the business domain itself.

This is the complexity that actually belongs.

Examples:

pricing rules,
eligibility constraints,
shipment state transitions,
reconciliation logic,
metadata rules,
legal behavior,
catalog semantics,
scheduling constraints.

This complexity exists because reality is complex.

You cannot remove it.

You can only understand it, model it, and localize it properly.

Accidental complexity

Accidental complexity is everything introduced by the solution that the problem itself did not require.

Examples:

framework conventions,
architectural ceremony,
messaging choreography,
unnecessary distribution,
layered indirection,
technical orchestration,
compensating workflows,
integration-driven domain shape,
“enterprise” abstraction stacks.

This complexity is not business truth.

It is construction overhead.

And much of modern software architecture is simply accidental complexity with better branding.

The first job of software design is not to choose an architecture

It is to understand the domain.

That should not be controversial.

And yet much of modern software development behaves as if the opposite were true.

Teams routinely begin with questions like:

Should we use CQRS?
Should we use EDA?
Should we split this into microservices?
Should this be event-driven?
Should we separate reads and writes?
Should this be asynchronous?
Should we introduce orchestration?

Those are not first questions.

Those are late questions.

The first question is:

What is the business, really?

Until that question is answered properly, every major architectural choice is at risk of being premature.

And premature architecture is usually just accidental complexity entering the system early enough to become permanent.

The real problem is Pattern-Driven Design

The issue is not that CQRS, EDA, or messaging can never appear in a system.

The issue is that many teams no longer design from the domain outward.

They design from patterns inward.

That is how software ends up shaped by:

command handlers,
event buses,
orchestration layers,
service templates,
and framework conventions

before anyone has actually understood what the business is.

That is not architecture.

That is Pattern-Driven Design.

And Pattern-Driven Design is one of the fastest ways to bury essential complexity under accidental complexity.

Because once the pattern becomes the starting point, the business no longer gets modeled on its own terms.

It gets forced to fit the machinery.

That is not simplification.

That is distortion.

Always start with the domain model

If the goal is to avoid expensive, brittle, overcompensated systems, then the starting point is straightforward:

Always start with the domain model.

Not because every system needs an elaborate object hierarchy.

Not because “DDD” is fashionable.

Not because object orientation is sacred.

But because if you do not start there, something else will define the shape of the software instead.

And that “something else” is usually accidental.

If you do not begin with:

what the business concepts are,
what they mean,
what they are responsible for,
what must always be true,
how they are allowed to change,
and how they interact,

then the system will instead be shaped by:

endpoints,
persistence structure,
framework constraints,
service boundaries,
message flows,
handler conventions,
or transport semantics.

And once that happens, the business is no longer being modeled.

It is being adapted to the machinery.

That is where software becomes expensive and brittle.

A user story is not a model

This is one of the most common and costly confusions in software teams.

A user story is not a model.

A ticket is not a model.

A process diagram is not a model.

A request from the business is not yet the business.

These things describe surface behavior.

They do not necessarily describe the actual structure or semantics of the domain.

That means implementation should never start by merely wiring the request into the chosen architecture.

It should start by asking:

What actually exists here?
What is this concept responsible for?
Which rules belong together?
Which state transitions are valid?
Which interactions are intrinsic?
Which behaviors are essential and which are incidental?

That is the real work of software design.

And the clearest place to do that work is the domain model.

A rich domain model is not overengineering

This is where a lot of modern teams have become confused.

There is a recurring assumption that a rich domain model is somehow “too much.”

But in practice, what often happens is not that the logic disappears.

It simply moves elsewhere.

If the business logic is not in the model, it will end up in:

services,
handlers,
orchestrators,
subscribers,
validators,
workflows,
pipelines,
process managers,
or framework glue.

That is not simplification.

That is displacement.

A rich domain model is not about making software “academic.”

It is about ensuring that the unavoidable business complexity lives where it is:

explicit,
cohesive,
inspectable,
and semantically meaningful.

In other words:

the model should contain the business.

Not the framework.

Not the message bus.

Not the choreography.

Not the deployment topology.

The business.

If the domain is simple, the model will be simple

This is where the usual objection appears:

“But not every system needs a rich domain model.”

Correct.

But that does not weaken the argument at all.

Because the real point is not that every system needs a complex model.

The point is:

every system should begin by discovering whether the domain is simple or complex.

And the correct place to do that is still the model.

If the domain turns out to be simple, then good.

The model will simply remain small and quiet.

That is not failure.

That is successful discovery of simplicity.

But deciding not to start there is a mistake.

Because then simplicity is not being discovered.

It is being assumed.

And assumed simplicity is one of the easiest ways accidental complexity gets invited in.

CQRS and EDA are often compensations for unclear modeling

Here is the part many people will resist.

That is fine.

CQRS and EDA are very often workarounds for bad design or not knowing how to model.

That does not mean they can never appear.

It means they should almost never appear as up-front architectural choices.

That distinction matters enormously.

They can absolutely emerge later as observations in retrospect.

But they should not be adopted as predefined frameworks before the domain has been understood.

Because once that happens, the architecture is no longer responding to the domain.

The domain is being forced into the architecture.

That is backwards.

CQRS is usually an observation, not a design starting point

Properly understood, CQRS is not something you “do.”

It is simply the recognition that:

the model used to change business state is not always the same model best suited for retrieving and navigating information.

That is all.

And sometimes that is perfectly valid.

A search engine like Lucene is a very good example.

The write side may simply persist documents or structured domain state.

The read side may support:

indexing,
tokenization,
ranking,
full-text search,
query optimization.

Those are not the same concern.

That is a natural asymmetry.

That is CQRS as an observation.

But that is very different from deciding on day one that the architecture will have:

command handlers,
query handlers,
buses,
mediators,
folders,
pipelines,
and all the associated ceremony.

That is not domain modeling.

That is accidental complexity pretending to be rigor.

Most CQRS implementations are just CRUD with bureaucracy.

EDA is often the same mistake, but with more latency

Event-driven architecture is often sold as if it were inherently sophisticated.

It is not.

Very often, it is simply a sign that direct responsibility was not modeled clearly enough.

There is a major difference between:

recognizing a domain fact,

and
externalizing causality into a distributed system.

Those are not the same thing.

A domain event can be a useful modeling concept.

But when every business consequence gets turned into:

a message,
a subscriber,
a consumer,
a queue,
a retry policy,
a dead-letter topic,
a compensating process,

then what often happened is not decoupling.

What happened is that one coherent business act was split into multiple technical acts — and the system now needs operational rituals to pretend they are still one thing.

That is not elegance.

That is fragmentation.

If an event is required for correctness, it belongs in the same transaction

This is where a lot of “event-driven” thinking falls apart.

If an event represents something the business considers part of the same completed action, then it should not be externalized into eventual consistency theater.

It should be processed within the same transactional consistency boundary.

Often that means:

same model,
same process,
same database transaction,
same JDBC transaction.

Because if correctness depends on:

retries,
cleanup,
compensating actions,
dead-letter queues,
reconciliation jobs,
or support scripts,

then the architecture has usually split apart something the business still considers one coherent act.

That is not decoupling.

That is a modeling failure disguised as scalability.

The simple rule is this:

If the business says these things are one thing, the software should not split them into many things.

Only effects that are genuinely:

external,
observational,
optional,
or secondary

should be allowed to escape the core transactional boundary asynchronously.

Everything else belongs together.

Microservices are often bad design with Kubernetes

And yes, the same critique applies to microservices.

Microservices are one of the most overprescribed and underjustified architectural choices in modern software.

They are usually discussed in terms of:

scaling,
team autonomy,
resilience,
independent deployment,
ownership.

But that framing hides the actual cost.

Because microservices are not just a deployment decision.

They are a fragmentation decision.

They force teams to commit to distributed boundaries early — often before anyone has proven those boundaries are semantically real.

And once the split is made, the business has to pretend those boundaries are natural.

That is how teams end up with:

cross-service workflows,
distributed invariants,
duplicated concepts,
compensating logic,
service orchestration,
and “eventual consistency” as a lifestyle.

That is not architecture.

That is often just what happens when one cohesive domain gets cut into pieces because “small services” sounded modern.

Logical cohesion comes before physical scale

This is where the usual counterargument appears:

“Yes, but what about scale?”

Fair question.

But scale does not rescue bad boundaries.

It amplifies them.

If you cannot model a business capability coherently in one process, you are very unlikely to improve it by scattering it across twenty.

That is because logical cohesion is a prerequisite for physical distribution.

A coherent system can sometimes be split later if reality genuinely demands it.

An incoherent system does not become better by being distributed.

It just becomes harder to debug, harder to reason about, and more expensive to keep alive.

So yes, scale matters.

But scale is not an excuse to abandon cohesion before you have even found it.

Small is not the goal. Cohesion is.

The phrase “microservice” already biases the conversation in the wrong direction.

Because it encourages optimization for smallness.

But smallness is not the goal.

Cohesion is the goal.

The real objective is:

semantically meaningful boundaries,
high internal density of behavior,
low cross-boundary coordination.

That is very different.

If one business action routinely requires orchestration across multiple internal services, the split is probably wrong.

That is one of the best architectural tests there is.

Because if the business still experiences something as one coherent operation, but the software requires:

service A,
then service B,
then service C,
then retries and compensations if one fails,

then the architecture has not discovered a boundary.

It has manufactured one.

And now it has to manage the damage.

The real cost of framework-first architecture is not implementation. It is drag.

This is where the economics become severe.

Bad architecture is not expensive merely because it takes slightly longer to build.

It is expensive because it creates organizational drag for years.

That drag shows up everywhere.

Slower feature development

Every change now has to move through machinery that was introduced before the business was properly understood.

So even small changes require:

coordination,
contract changes,
handler updates,
event flow changes,
service touchpoints,
deployment sequencing,
orchestration review.

That is not domain complexity.

That is architecture tax.

More defects and harder recovery

When one coherent business action has been fragmented across:

services,
queues,
projections,
retries,
and compensations,

then failure handling becomes vastly more expensive.

The question is no longer:

“Did the business rule execute correctly?”

It becomes:

“Which part of the distributed choreography failed, and what state is the system now in?”

That is a much more expensive problem to solve.

Permanent cognitive overhead

This is one of the biggest hidden costs in software.

A misaligned architecture forces every engineer to carry extra mental load just to understand the system.

Instead of reasoning directly about the business, they must first reason about:

the framework,
the orchestration model,
the service topology,
the event timing,
the deployment shape,
the technical conventions.

That means every change is more mentally expensive than it should be.

And because salaries are the dominant cost in software, cognitive inefficiency is financial inefficiency.

The architecture becomes a second problem

At some point, the software is no longer difficult because the business is difficult.

It is difficult because the architecture has become a second problem layered on top of the first.

The system is now solving:

the business domain, and
the consequences of its own design choices.

That is pure waste.

And because most teams never built the tractor version, they often do not even realize how much of their effort is going into supporting the machine rather than solving the problem.

That is the uniqueness trap again.

The most expensive architecture is not the one that fails immediately

It is the one that:

works just enough,
survives just long enough,
and obscures its own cost just well enough

that nobody ever questions whether the machine was appropriate in the first place.

That is what makes framework-first architecture so dangerous.

It often does not fail loudly.

It succeeds expensively.

And that is much worse.

Because visible failure can trigger redesign.

But expensive success gets institutionalized.

It becomes:

“our platform,”
“our standard architecture,”
“our scalable foundation,”
“our engineering maturity.”

When in reality, it may just be a Ferrari that the organization has spent five years trying to teach to plow a field.

The first responsibility of software architecture is not scalability

It is not flexibility.

It is not “future-proofing.”

It is not pattern compliance.

It is not cloud nativeness.

It is not distributed elegance.

It is this:

to make the essential complexity of the business explicit, cohesive, and understandable.

That is the job.

Everything else comes later.

And if the software cannot explain the business clearly through its model, then it is not well architected — no matter how many services, handlers, events, buses, frameworks, or diagrams surround it.

Because at that point, the architecture is no longer serving the business.

The business is serving the architecture.

And that is why so much modern software is too expensive and too brittle.

A much better default

A better architectural instinct is this:

Do not ask what architecture you can build.

Ask what architecture the domain actually justifies.

And if the answer is:

smaller,
more cohesive,
more local,
less distributed,
less framework-driven,
and more explicit in its model

than current fashion prefers, that is not a sign of immaturity.

It is often a sign that the problem is finally being understood.

The next time a team is asked to “choose an architecture,” the first question should not be:

Which framework?
Which pattern?
Which cloud primitive?
Which service template?

It should be:

What is the business, and what is the cheapest, most coherent way to represent it truthfully?

Because software does not become expensive and brittle by accident.

It becomes expensive and brittle when teams choose machinery before they understand the work.

And from that point on, they do not just have a domain to solve.

They also have an architecture to survive.

That is not engineering maturity.

That is paying interest on a design mistake.

When CI/CD Becomes the Goal: The Quiet Erosion of Engineering Ownership

Leon Pennings — Mon, 30 Mar 2026 06:04:01 +0000

Software delivery has become one of the most ritualized practices in modern development.

Pipelines are longer.

Checks are stricter.

Deployments are more automated.

Dashboards are greener than ever.

Yet in many teams, software has not become more engineered.

It has become more processed.

That distinction matters.

CI/CD was never intended as an excuse to pile machinery on top of weak engineering. It started as a practical response to real problems. But somewhere along the way, much of the industry stopped using it to support strong engineering and began using it to compensate for its absence.

That is where things quietly went wrong.

What CI Originally Solved

The original idea behind Continuous Integration was straightforward.

It was never primarily about pipelines, YAML, or branch policies. It was about forcing reality into the room early.

Developers were expected to integrate frequently — often daily — into a shared codebase. The goal was simple: prevent teams from drifting into parallel worlds and discovering too late that their work didn’t fit together.

That solved a real problem.

Frequent integration forced teams to confront overlap, collisions, ambiguity, and unintended coupling while the cost of correction was still low. But CI did something subtler and arguably more important: it reinforced the team while development was still happening.

Developers didn’t merely discover each other’s work after the fact. They had to continuously adapt to one another’s choices, assumptions, and interpretations of the system in the moment. That pressure was not a flaw. It was the point.

This is how engineering sharpens itself — not by letting everyone disappear into isolated implementation tunnels and comparing answers at the end, but by shaping and correcting each other during the act of construction. Real engineering teams do not just divide work. They reinforce shared understanding.

Original CI made integration a living team concern rather than a delayed administrative event.

That was healthy engineering.

What Continuous Delivery Originally Solved

Continuous Delivery was aimed at a different concern than CI.

Not integration itself, but the path from integrated code to running software.

And to be fair, that was not a fake concern.

But it also was not universally the disaster modern delivery culture sometimes pretends it was.

In many Java systems, deployment was already fairly boring. An application server was stopped, a WAR or EAR was replaced, the instance was restarted, and the system was verified. That was not always elegant, but neither was it some fundamental engineering crisis.

So the real value of CD was not that it magically solved an impossible deployment problem.

Its promise was narrower and more practical: to make the release path more repeatable, more standardized, less person-dependent, and easier to execute consistently across teams and environments.

That is a reasonable goal.

And in some environments, it becomes more than reasonable — it becomes necessary.

Once deployments span multiple machines, rolling restarts, clustered services, or orchestrated server fleets, manual deployment stops being merely inconvenient and starts becoming operationally impractical. At that point, automation is not theater. It is simply the sane way to move software safely and consistently.

That is where CD has real value.

But not all release friction was technical.

In many organizations, a significant part of the “deployment problem” came from the surrounding structure itself: separate infrastructure departments, ticket-driven handoffs, release scheduling rituals, and operational processes that turned even simple deployments into expensive coordination exercises.

That pain was real — but it is important to name it accurately.

Often, the difficulty was not in replacing the software.

It was in navigating the organization around it.

Modern delivery automation did remove a great deal of that friction.

But in many cases, the underlying pattern did not disappear. It simply moved.

Where infrastructure teams once controlled servers and release windows, platform and pipeline teams now increasingly control the mechanics of delivery itself. The form changed. The separation often did not.

And that matters more than it first appears.

Because once the release path is defined by people who do not carry the semantic or business consequences of the software, the pipeline can quietly become a surrogate for ownership.

That is where the trade-offs began.

Where It Started to Go Wrong

The issue is not that CI/CD solved fake problems. The issue is that much of the industry adopted the tooling and rituals while quietly abandoning the engineering assumptions that gave those practices their value.

Once that happened, CI/CD stopped reinforcing good engineering and started compensating for weak engineering instead.

A lot of what now passes for “CI” is no longer continuous integration.

It is deferred reconciliation.

Developers work in isolation on long-lived branches, treating the merge as the first serious moment of contact with the rest of the system. The pain that CI was designed to expose early is now allowed to accumulate until the branch is “ready.” The pipeline creates the illusion of discipline, but the underlying practice has shifted.

The old model forced developers to adapt to each other continuously.

The modern branch-heavy model lets them adapt only at the end.

What makes this regression more serious is that it did not happen accidentally. In many teams, CI was gradually reshaped to serve a different goal: continuous deployment of independently developed changes.

That sounds efficient, but it came with a structural trade-off.

In order to deploy “each feature” continuously, work first had to become isolatable. That pushed development toward branch-based workflows, delayed integration, and feature-level thinking. The unit of progress stopped being the continuously evolving shared system and became the individually shippable change.

And once that shift happened, CI changed with it.

What used to be immediate feedback on a real check-in against the shared codebase became a staged validation process around isolated work. The branch is tested. The pull request is reviewed. The pipeline is green. But the fully integrated system — in motion, under changing conditions, with multiple real changes meeting each other — is often encountered meaningfully much later.

That is not a small process adjustment.

It is a relocation of feedback.

And when feedback moves later, risk moves with it.

The Social Cost Nobody Mentions

This changes far more than code flow.

It changes the social structure of development itself.

Instead of reinforcing each other during construction, developers increasingly become delayed reviewers, test-runners, or approval gates. The shared act of building gives way to a serialized process of isolated work followed by late validation.

That may still produce working software, but it does not produce the same quality of team thinking.

The old model created friction early, while people were still shaping the solution together. The newer model often postpones that friction until after mental commitment has set in. At that point, integration becomes negotiation rather than collaboration.

That is a significant regression.

A team stops behaving like a team.

It starts behaving like a collection of individuals working in parallel and negotiating reality afterward.

And once that happens, the pipeline begins to replace the team as the thing that “validates” software.

That is a dangerous substitution.

Because a team can challenge assumptions, surface ambiguity, and expose misunderstandings while the system is still being shaped.

A pipeline cannot.

It can only tell you whether a predefined process passed.

It cannot tell you whether the software still makes sense.

The Illusion of Delivery Maturity

Continuous Delivery has suffered a parallel fate.

In theory, CD makes deployments safe by making them repeatable. In practice, many teams achieve “safety” by surrounding brittle systems with ever-growing layers of process, abstraction, and automation. The application becomes harder to understand. The deployment model grows more complex. And the pipeline swells to absorb complexity that should never have existed in the software itself.

Eventually, the release system becomes more elaborate than the software it delivers.

This raises an uncomfortable question:

Are we automating a healthy system, or are we automating around an unhealthy one?

If deployment is difficult, brittle, or mysterious, there are usually only two explanations:

The system genuinely operates in a complex environment.
The software was never designed with operability in mind.

The first is sometimes unavoidable.

The second is too often ignored.

Good Deployment Begins in Design

Much deployment pain is treated as the inevitable cost of “modern systems.” In many business applications, that pain is not inevitable — it is designed in.

A well-engineered application should be deployable because it was built to be deployable: operational state kept where it belongs, environment-specific behavior minimized, startup made deterministic, migrations treated as part of the lifecycle, and only what truly needs to vary externalized.

When deployment is simple by design, the need for pipeline heroics drops dramatically.

Automation then becomes what it was meant to be: a way to remove repetition and error from a sound process — not a bandage for an unsound one.

The Dangerous Slide into “Production as Test Environment”

This is where the earlier shift becomes dangerous.

When integration is no longer happening continuously during development, reality does not disappear.

It simply waits.

And increasingly, that reality is encountered much later — often in environments close to or inside production.

This is why so many modern delivery models quietly drift toward using production as their final validation environment. Not because teams explicitly decide to “test in production,” but because the system as a whole often meets changing real-world conditions there more meaningfully than anywhere before it.

That is a very different feedback model from original CI.

Original CI gave teams rapid feedback on check-ins against a shared and continuously evolving codebase. Modern branch-heavy CI/CD often gives rapid feedback on isolated changes, then relies on deployment frequency to surface what only the integrated whole can reveal.

That is not the same kind of safety.

It is simply a different place to discover reality.

Smaller and faster deployments are often presented as inherently safer.

But that is only true if one quietly assumes that the meaning and impact of a change are already well understood.

In practice, that is often exactly what is not true.

A smaller deployment unit may reduce rollback scope or make blame attribution easier, but that is not the same as reducing actual engineering risk. If anything, the opposite can happen: the change is seen by fewer people, discussed less deeply, and integrated less continuously before it reaches production.

That does not reduce uncertainty.

It merely packages uncertainty into smaller increments.

And when production changes multiple times per day, stability itself begins to shrink. The system is only as stable as the scenarios already captured in the automated tests — tests which are themselves usually adapted to the most recent expected path into production.

That creates a dangerous illusion of control.

The software appears validated, but only within the shrinking boundary of what was recently anticipated.

The Semantic Risk Pipelines Cannot See

More importantly, the true impact of a change is often not visible from the code itself.

A seemingly trivial modification for a developer can carry major domain consequences. And a technically substantial change can sometimes be domain-trivial. That asymmetry matters.

Because developers are not domain experts.

They can understand the implementation, but they cannot reliably infer the full business meaning of a change from code alone — not without sustained discussion and feedback from people who actually understand the domain.

And the most dangerous part is that this is not predictable.

It is not true that every change requires deep domain validation.

But it is also not reliably obvious which changes do.

That is exactly why semantic risk cannot be reduced to diff size, deployment frequency, or pipeline confidence.

Many of the hardest failures are not technical crashes or exceptions. They are semantic failures: the system behaves exactly as the code and tests dictate, yet wrongly according to the business.

That is where domain experts matter.

And no amount of deployment frequency changes that fact.

Human Validation Is Not the Enemy of Engineering

One of the stranger modern assumptions is that removing human judgment from the release path is always progress.

It is not.

There is a crucial difference between automating repeatable mechanics and eliminating deliberate validation. Those should never be conflated.

A strong delivery process should automate the mechanical parts — build, package, verify, deploy to controlled environments, reproduce release steps consistently.

That is sensible.

But whether a business-critical change should be exposed to real users is not always a purely technical question. In many systems, it is also a domain question.

Human validation is not a sign of immaturity. Sometimes it is the last remaining sign that someone still understands the difference between technical correctness and business correctness.

That distinction is too often lost.

Application Quality Is Not Generated By Tooling

Part of the problem is that “quality” itself has increasingly been redefined through the lens of tooling.

In many organizations, delivery practices are no longer primarily shaped by engineers with deep ownership of the software and its domain. They are shaped by process-specialized roles, platform teams, and tooling consultants whose authority often comes from familiarity with delivery systems rather than from responsibility for the software’s behavior, design, or business consequence.

That changes what gets optimized.

Quality slowly stops meaning clarity, simplicity, robustness, and domain correctness.

It starts meaning compliance: green pipelines, approved stages, scan completion, branch policy adherence, and process conformance.

Those may be useful signals.

But useful signals can become dangerous substitutes.

And that is how problem analysis gets replaced by cargo cults.

The Real Regression: Loss of Ownership

Underneath all of this lies a deeper problem than pipelines or deployment buttons.

The quiet regression is the loss of engineering ownership.

Modern delivery culture has made it increasingly possible for developers to produce deployable software without truly understanding:

how the system runs
how it is released
how it evolves
how it fails
how it behaves in production
how it fits the business domain as a whole

That is not progress.

That is separation from consequence.

Once that separation occurs, the pipeline stops being a tool.

It becomes a substitute for engineering responsibility.

Pipelines can tell you whether something passed the process.

They cannot tell you whether the software is truly understood.

What Healthy CI/CD Should Actually Look Like

Good CI/CD is not about maximum automation.

It is about preserving engineering discipline while reducing mechanical waste.

That usually looks far less glamorous than modern tooling culture suggests:

Developers integrate continuously into a shared mainline
Incomplete work is handled through discipline and design, not default branch isolation
Build and verification are automated and fast
Deployment to lower environments is repeatable and low-friction
Acceptance happens in a controlled way
Production deployment is simple enough to trust
Human validation exists where domain risk justifies it
The release path is designed to support ownership, not replace it

That is not anti-automation.

It is anti-theater.

And that distinction matters.

The Real Question

CI/CD is not really a tooling question.

It is a quality question.

The real issue is not whether a team has pipelines, feature flags, deployment jobs, or environment promotion stages.

The real issue is this:

Does the delivery process reflect a well-engineered system and a team that understands it — or is it compensating for the absence of both?

That is the question most teams avoid.

Because if the honest answer is the second one, then the pipeline is not a sign of maturity.

It is camouflage.

And that may be the most uncomfortable truth in modern software delivery:

sometimes what looks like engineering progress is really just process growth around declining engineering depth.

CI/CD used as a substitute for the very discipline it was supposed to support.

And once that happens, delivery stops being an expression of engineering quality.

It becomes a process for moving misunderstood software into production more efficiently.

Software Testing: You’re Probably Doing It Wrong

Leon Pennings — Thu, 26 Mar 2026 08:32:29 +0000

Software testing has become one of the most ritualized practices in modern development.

That is not because testing is unimportant. Quite the opposite.

Testing matters.

But in many teams, testing has quietly expanded beyond its actual role. It is no longer treated as a tool for verifying software behavior. It is increasingly treated as a proxy for understanding, a proxy for design, and even a proxy for quality itself.

And that is where the problem begins.

Because testing can verify behavior.

But it cannot replace engineering.

Testing in Software Is a Verification Discipline

At its core, testing in software has a very specific role:

to verify whether a system behaves acceptably under certain conditions.

That is valuable. Necessary, even.

A good test can help answer questions like:

Does this behavior still work?
Does this input still lead to the expected output?
Did this change introduce a regression?

That is where testing is strong.

But notice what testing does not answer:

Is the design coherent?
Is the architecture proportional to the problem?
Is the model a good representation of the domain?
Is this implementation economical to evolve?

Those are engineering questions.

And when teams start treating test suites as if they answer them, behavioral verification gets confused with software quality itself.

That is a costly mistake.

The Math Test Problem

A great deal of modern team testing resembles cheating on a math exam.

Imagine students defining the exam questions during class, together with the teacher, while learning the material. By the time the exam arrives, the goal is no longer to understand the mathematics. The goal is to reproduce the answers that were already agreed upon.

Something very similar happens in software teams.

During refinement, development, or collaborative scenario-writing sessions, expected behavior is often defined in detail in advance. Tests are written, scenarios are formalized, and the team aligns around them.

In theory, this sounds excellent.

In practice, it introduces a subtle distortion:

the implementation target shifts from understanding the business domain to passing the agreed test scenarios.

That is a very different goal.

The result is not necessarily a bad system. But it is often a system optimized for compliance rather than understanding.

And the danger is obvious:

how often is the first interpretation of a business need fully correct?

If the test scenarios are based on incomplete understanding, then all the rigor in the world only helps build the wrong thing more reliably.

Verification Is Not Validation

This is the distinction many teams lose.

Testing is very good at verification:

Did the implementation behave as intended?
Does the system still behave as expected?

But verification is not the same as validation:

Was the right thing built?
Is this actually a fitting solution for the domain?

A system can satisfy every agreed scenario and still be fundamentally wrong.

It can behave correctly while being poorly modeled.

It can produce the expected output while being overcomplicated.

It can pass every acceptance test while solving the wrong problem in the wrong way.

In other words:

A passing test suite proves behavioral agreement—not solution fitness.

And that distinction matters far more than many teams admit.

The Ferrari in the Field

A Ferrari F40 can absolutely move across a field.

It can produce motion. It can get from one side to the other. It can, in the most literal sense, “do the job.”

That does not make it a tractor.

The same is true in software.

A system can satisfy all functional expectations and still be the wrong machine for the domain. It can be too expensive to change, too fragile to extend, too over-engineered for the actual need, or too structurally rigid to survive evolving business requirements.

Testing does not expose that.

Because testing can tell whether the machine moves.

It cannot tell whether it is the right machine.

And that is not a trivial distinction.

That is the distinction between working software and good engineering.

When Tests Stop Following Behavior and Start Following Structure

This is where testing often becomes actively harmful.

If testing is a behavioral verification discipline, then it should limit itself to verifying behavior.

But many modern testing practices go deeper than that.

They start testing:

local call structures
internal collaborations
class-level decomposition
implementation fragments in isolation

At that point, the tests are no longer verifying the system in any meaningful way.

They are verifying the current shape of the code.

That is not the same thing.

And once that happens, the test suite stops protecting change and starts resisting it.

The moment a test depends on how the behavior is achieved instead of what behavior is observed, it becomes a brake on refactoring.

That is one of the most under-discussed quality problems in software teams.

Because now every structural improvement becomes expensive:

rename a collaborator → tests break
merge responsibilities → tests break
simplify orchestration → tests break
move logic to a better abstraction → tests break

Not because behavior changed.

But because the test suite was never really about behavior to begin with.

Why Isolated Class Testing Often Misses the Point

One of the clearest examples of this problem is isolated class testing.

A class exists in code. Therefore, many teams assume it should be testable independently.

But a technical unit is not automatically a meaningful behavioral unit.

That assumption is rarely challenged.

Take something like a PDF information extractor.

That behavior does not meaningfully exist in a vacuum. It depends on:

parsing logic
normalization logic
extraction rules
object interpretation
domain-level decisions

Yet what often happens?

A single class gets tested in isolation.

Its collaborators are mocked.

Its environment is simulated.

Its context is stripped away.

Now the test no longer asks:

“Can the system reliably extract useful information from PDFs?”

Instead, it asks something far weaker:

“Does this one implementation fragment behave under synthetic scaffolding?”

That is not meaningful verification.

That is structural rehearsal.

And the cost is not just conceptual—it is practical.

Because now the test suite is coupled to a local decomposition that may not even survive the next decent refactor.

We end up with a test suite that passes perfectly even if the integration between those fragments is fundamentally broken—because we’ve tested the components, but ignored the composition.

Coverage Is Not Confidence

Test coverage is another example of verification ritual turning into proxy engineering.

Coverage has become a metric in its own right.

Teams report it. Managers ask for it. Pipelines display it as if it were a signal of quality.

But coverage says only one thing:

this code was executed while a test ran.

That’s it.

It does not tell:

whether the test is meaningful
whether important behavior is protected
whether the assertions matter
whether the design is safe to evolve

And yet teams optimize for it anyway.

That leads to the usual absurdities:

getter/setter tests
trivial constructor tests
one-line branch inflation
synthetic assertions written only to satisfy the metric

This is not quality.

It is administrative theater.

Coverage is a measure of execution, not a measure of insight.

And once a team starts chasing the number instead of the confidence, the metric has already failed.

Testing Is Not a Design Discipline

This may be the most important point of all.

Testing can verify whether software behaves as expected.

It cannot tell whether the software is well-designed.

It cannot tell whether:

the abstraction boundaries are good
the model is coherent
the architecture is sustainable
the implementation cost is proportional to the value
future stories will remain easy to add

Those are not test outcomes.

Those are design and engineering concerns.

And if a team replaces those concerns with:

framework templates
scenario scripts
coverage thresholds
pipeline greenness

…then better engineering is not happening.

Judgment is simply being outsourced to artifacts.

That may feel safer.

It may even look more rigorous.

But it is still a substitute for actual thought.

What Testing Is Actually For

Testing does have a real and valuable place.

Used well, testing is for:

verifying externally observable behavior
protecting against meaningful regressions
increasing confidence during change
supporting safe evolution of a system

That is already enough.

Testing does not need to become:

a replacement for design
a replacement for domain understanding
a replacement for architecture
a replacement for engineering judgment

The moment testing is asked to do those things, it becomes overloaded.

And overloaded tools do not become more powerful.

They become more misleading.

The Cost of a Misaligned System

A system does not need to be broken to be expensive.

It only needs to be misaligned.

That is one of the most dangerous illusions in software development: if the system behaves correctly, it is easy to assume the engineering must also be sound.

But a system can pass tests, satisfy stories, and still be fundamentally costly in all the places that matter over time.

It can be:

too expensive to extend
too brittle to refactor
too complex to reason about
too rigid to absorb new requirements cleanly

This is the software equivalent of using a Ferrari F40 to plow a field.

The machine moves.

The task gets completed.

But every future change becomes more expensive than it should be.

That cost rarely appears in the first implementation. It appears later:

in slower feature development
in rising maintenance effort
in increasingly fragile changes
in the growing difficulty of correcting earlier assumptions

And this is precisely where testing, on its own, offers very little protection.

Because testing can confirm that a system still behaves the same.

It cannot tell whether that behavior is now trapped inside the wrong machine.

That is an engineering problem.

And when that distinction is missed, software quality gets reduced to present-day correctness while long-term adaptability quietly deteriorates.

Conclusion

Software engineering has become increasingly comfortable with proxies.

Metrics are used as substitutes for judgment.

Artifacts are used as substitutes for understanding.

Test suites are used as substitutes for design confidence.

And in doing so, many teams create the appearance of rigor while quietly undermining the adaptability of the system itself.

Testing is valuable.

But only when it stays in its lane.

Testing should verify software behavior. It should not define the software, freeze its structure, or pretend to certify its design.

Because the moment verification starts replacing engineering, pipelines may still signal green — but better systems do not follow.

Ferraris get built where tractors would have been enough.