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.

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.

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:

1. the business domain, and

2. 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.

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.

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.

At its core, Agile shortens the feedback loop between business intent and working software—to expose ideas early, validate them quickly, and adapt continuously. The goal was never just to build software, but to discover what the business actually needs by building it.

Somewhere along the way, many teams drifted. User stories became work orders instead of expressions of intent. Refinement became premature implementation design instead of shared understanding. And the feedback loop quietly stretched back to the end of the sprint.

The Problem with User Stories as Work Orders

A good user story expresses intent: What is the user trying to achieve, and why does it matter?

In practice, stories too often look like predefined solutions:

• “I want a button in the top right corner to search.”

• “Add a ‘costs’ field to each order.”

These constrain the solution space from the start. Better alternatives go unexplored. The system quietly accumulates unnecessary complexity.

What’s missing is the actual problem: Is this about searching, or about finding something quickly? Is this about storing costs, or about understanding profitability?

Without that clarity, we aren’t building solutions—we’re implementing assumptions.

Refinement as Understanding, Not Design

Refinement is where the misunderstanding should be corrected. Yet too many sessions devolve into:

• “Where should the button go?”

• “What fields do we need?”

• “How do we implement this?”

That is early design on incomplete information.

Real refinement focuses first on:

• Intent: What is the user truly trying to achieve?

• Context: When and why does this happen?

• Available information: What does the user already know?

• Problem type: Is this a lookup, exploration, or navigation task?

Only after the problem is clearly understood should solution ideas emerge.

A Practical Example: When “Search” Isn’t Search

In an ETL context, a functional manager requests a search feature. On the surface it sounds reasonable. Dig deeper, though, and the real need surfaces:

The manager is often asked by a colleague (or for their own reference) to pull up a specific case. They have only a vague description of the object type and when it occurred. The goal isn’t broad exploration—it’s identification and direct navigation.

Instead of a generic search system, a far simpler solution appears:

• Use meaningful, relatable identifiers (a combination of object type and unique ID).

• Enable direct navigation via those identifiers.

• Add contextual links to related cases.

The result is simpler, faster, and far better aligned with actual usage.

This is refinement at its best: turning vague requests into precise problem definitions.

Mirror Pieces: The First Implementation Is Not the Product

Even strong refinement leaves understanding theoretical until it meets reality. That’s where the first implementation enters—not as a finished deliverable, but as a mirror piece.

A mirror piece is:

• A minimal, functional slice of the system.

• Built specifically to reflect business intent back to stakeholders.

• Deliberately incomplete and open to rapid change.

Its real purpose isn’t immediate value. It answers a more important question: “Is this what you meant?”

By creating mirror pieces early, teams shift from end-of-sprint validation to continuous feedback during development.

Why a UI Is Crucial—Even for Technical Systems

A mirror piece without a UI is often invisible to the business. Raw data, logs, or backend flows require interpretation, reopening the very gap we’re trying to close.

A simple, even rough UI changes everything. It provides:

• Observability: What is actually happening in the system?

• Navigability: How do entities relate (e.g., DeliveryUnit → PreservationUnit)?

• Clarity: Does this match how the business understands the domain?

The UI becomes the event horizon—the meeting point of business intent and technical execution. Without it the system stays abstract. With it, the system becomes a shared language.

Refinement in a Living System

No story arrives in a vacuum. Every new request lands inside an existing system—complete with implemented logic, established flows, and embedded assumptions about how the business works.

Refinement must therefore do double duty: deeply understand the new intent and re-evaluate what already exists.

The first question shifts from “How do we build this?” to “How does this relate to what we already have?”

New stories often reveal deeper truths:

• An earlier assumption was incomplete.

• A rule was too simplistic.

• A flow was designed for a narrower case than reality demands.

This is not failure—it is the system doing its job: exposing gaps in understanding.

When a story interacts with existing behavior, there are typically three paths:

1. It fits the current model → Simply extend what is already there.

2. It introduces a variation within the same flow → Isolate the difference cleanly (e.g., using strategy-like patterns) without fracturing the stable core.

3. It challenges earlier assumptions → Revisit and evolve the underlying model itself.

Treating all three the same—by just adding patches or conditionals—breeds accumulating complexity, duplicated logic, and a system that grows harder to reason about.

In this light, refinement becomes far more than story clarification. It is a checkpoint for system integrity: a deliberate moment to ask, “Does our current system still reflect how the business actually operates?”

Software is not a static machine. It is an evolving mirror of the domain. Every new story offers a chance to confirm, refine, or correct what we thought we knew. Refinement is where that evolution should happen consciously—not accidentally through technical debt.

The Real Cost of Skipping Intent-Focused Refinement

When refinement stays shallow and we build on assumptions instead of understanding, the consequences are predictable:

• Misaligned solutions.

• Duplicated or conflicting functionality.

• Growing technical debt.

• Late and expensive rework.

• Systems that pass internal checks but fail in real use.

Most importantly, the system stops being a tool for learning and becomes a machine for executing yesterday’s assumptions.

Reclaiming the Feedback Loop

The original promise of Agile was fast, continuous feedback. To reclaim it, we need a mindset shift:

• From stories as work orders → to stories as intent.

• From refinement as design → to refinement as understanding.

• From implementation as delivery → to implementation as a mirror.

• From end-of-sprint feedback → to continuous feedback through mirror pieces and early UI.

Conclusion

Software development is often treated as a delivery process. In reality, it is a learning process.

The goal is not merely to build what was asked. The goal is to discover what is actually needed.

Refinement, mirror pieces, early UI, and deliberate validation are not overhead. They are the mechanisms that make genuine learning possible.

Software is not just a tool to serve the business.
It is a mirror that helps the business—and the team—understand itself.

The sooner we look into that mirror, the better what we build will become.

In the Age of AI: Where Does AI Fit?

Looking at refinement as understanding, mirror pieces as feedback, and software as a learning tool, the natural question arises: Where does AI fit?

AI excels at implementation:

• Translating well-understood requirements into code.

• Generating boilerplate and structure.

• Accelerating familiar patterns.

In short: AI operates most effectively in the solution space.

The central challenge in this article lies elsewhere—in understanding intent, interpreting context, challenging assumptions, and discovering what the problem actually is. That remains fundamentally human work.

AI introduces a subtle risk. Because it can generate working code so quickly, it creates an illusion of progress even when understanding is incomplete. If refinement is weak:

• AI will still produce code.

• The system will still behave as specified.

• Tests will still pass.

But the result is simply a faster realization of the same flawed assumptions.

AI doesn’t correct misunderstanding—it accelerates it.

What AI makes unmistakably clear is something that was always true: writing code is often the easiest part of building software. The real difficulty lies in knowing what to build, understanding why it matters, and recognizing when our assumptions are wrong.

That is exactly where strong refinement, mirror pieces, and early feedback matter most.

Within the model described here, AI fits naturally:

• Refinement → human-driven discovery.

• Mirror pieces + UI → shared validation.

• AI → accelerated implementation of what has been learned.

AI lets teams build mirror pieces faster, iterate more quickly, and validate ideas sooner. But it does not replace the need for discovery—it makes that discovery loop more critical, not less.

Final Note

If software development becomes a process of executing predefined solutions, AI will do that exceptionally well.

But if we treat it as a process of learning and deeply understanding a domain, then AI becomes a powerful tool—without ever being the one that asks the important questions.

And those questions are still where the real work begins.

• reduce boilerplate

• write less code

• increase conciseness

Frameworks, annotations, and code generators promise cleaner classes and faster development. Tools in ecosystems like Spring Boot emphasize exactly that: less code, less friction, more output.

At first glance, this seems like obvious progress.

But it raises a fundamental question:

Does writing less code actually lead to better software?

The Appeal of Code Reduction

Code reduction is attractive because it delivers immediate, visible results:

• fewer lines of code

• less repetition

• faster initial development

A class with 200 lines becomes 50. Configuration disappears behind annotations. Common patterns are abstracted away.

From a distance, this looks like improvement.

And at the level of syntax, it is.

The Problem: Optimizing the Wrong Layer

Reducing boilerplate optimizes how we write code.

It does not address:

• what the code represents

• how responsibilities are defined

• whether the model is correct

In other words:

It improves expression without improving meaning.

You can have:

• perfectly concise code

• minimal syntax

• elegant constructs

…that still represent a poor understanding of the domain.

And when that happens, the system remains:

• hard to understand

• fragile under change

• difficult to extend

No amount of syntactic improvement fixes that.

The Missing Dimension: The Story

A well-designed system tells a story.

Not in comments or documentation, but in its structure:

• objects represent real concepts

• behavior lives where it belongs

• interactions reflect actual processes

You can read the code and understand:

what the system does and why

This is the “story” of the system.

And it is where most of the value lies.

Why Less Code Doesn’t Mean a Better Story

Reducing code does not automatically improve that story.

In many cases, it does the opposite.

Consider what often happens:

• explicit logic is replaced with annotations

• behavior is hidden behind framework conventions

• configuration replaces clear structure

The result:

• less visible code

• but more implicit behavior

And implicit behavior is harder to reason about.

You didn’t remove complexity.

You made it harder to see.

The Illusion of Simplicity

Code reduction creates a powerful illusion:

If there is less code, the system must be simpler.

But simplicity in software is not about size.

It is about:

• clarity of responsibilities

• correctness of the model

• predictability of behavior

A small, unclear system is more complex than a larger, well-structured one.

And a concise system with hidden behavior is more dangerous than an explicit one.

When Code Reduction Helps

This is not an argument against reducing boilerplate.

There are clear benefits:

• eliminating repetition

• removing mechanical code

• standardizing common patterns

When applied carefully, code reduction can:

• improve readability

• reduce noise

• allow focus on important parts

But only under one condition:

The underlying model must already be sound.

When It Becomes Harmful

Code reduction becomes problematic when it is used as a substitute for thinking.

When teams focus on:

• making code shorter

• following framework conventions

• reducing visible complexity

Instead of:

• modeling the domain

• defining responsibilities

• understanding behavior

At that point, development becomes:

an exercise in fitting problems into existing constructs

Rather than solving them.

When the Story Disappears

If software engineering increasingly focuses on syntax optimization—on writing less code, faster—then an important question emerges:

Who is responsible for the quality of the story?

Because if we optimize for:

• fewer lines of code

• more generation

• less manual effort

We also reduce something else:

the amount of direct engagement with the model itself

Traditionally, writing code served a dual purpose:

• implementing behavior

• validating understanding

The act of writing forced decisions:

• where does this responsibility belong?

• does this concept make sense?

• do these rules contradict each other?

Code was not just output.

It was a mirror.

The Role of Friction

Some level of friction in development is valuable.

Not accidental friction—like fighting a framework—but conceptual friction:

• needing to define boundaries

• needing to resolve ambiguity

• needing to make trade-offs explicit

This friction forces clarity.

It exposes:

• inconsistencies in requirements

• gaps in understanding

• misplaced responsibilities

When you remove too much of that friction, you don’t just gain speed.

You lose feedback.

Code Generation as the Endgame

Tools like Claude and similar code generation systems represent the logical extreme of this trend.

They can:

• generate large amounts of code instantly

• remove almost all boilerplate

• translate intent into implementation

From a productivity standpoint, this is remarkable.

But it introduces a new risk:

If code is no longer written, it is no longer used to think.

When “Working” Is No Longer Proof

Traditionally, writing code forced validation.

Each decision had to be made explicitly:

• where does this behavior belong?

• do these concepts align?

• are these rules consistent?

In that process, contradictions surface.

With code generation, that feedback loop weakens.

You describe intent.
The system produces implementation.

And because the result runs, it creates a powerful signal:

It works.

But that signal is misleading.

What you get is not necessarily a system that is correct.

It is a system that appears to work under current conditions.

The Silent Failure Mode

Without active engagement in shaping the model:

• contradictions in the domain are not surfaced

• responsibilities are not fully resolved

• assumptions are not challenged

They don’t disappear.

They remain latent.

And instead of being caught during construction, they emerge later as:

• inconsistent behavior

• edge-case failures

• unpredictable interactions

At that point, the problem is no longer local.

It is systemic.

The Loss of Pressure on the Model

A well-designed system is not just built—it is continuously refined.

Each line of code adds pressure:

• on the model

• on the boundaries

• on the assumptions

Code generation removes much of that pressure.

It allows systems to grow without forcing the same level of scrutiny.

So the model is no longer:

• shaped

• challenged

• corrected

It is merely extended.

From Engineering to Assembly

The risk is not that code generation produces bad code.

The risk is that it enables a different mode of development:

assembling systems without fully understanding them

At small scale, this works.

At larger scale, it leads to:

• hidden inconsistencies

• fragile structures

• systems that behave correctly—until they don’t

And when they fail, they fail in ways that are:

• hard to trace

• hard to reason about

• hard to fix

The Real Risk

The danger is subtle.

The system does not immediately break.

It delivers output.
It passes tests.
It supports current use cases.

But underneath:

the model has never been fully validated.

And over time, that leads to a system that is not truly stable, but:

conditionally correct and fundamentally unpredictable

Closing Thought

Code generation removes effort.

But it also removes something essential:

the act of forcing clarity through construction

And without that:

we risk building systems that don’t fail fast—
but fail late, and fail hard.

It works. Requests flow through the system. Data is persisted. Features get delivered.

By most organizational standards, this is considered a success.

But there’s a fundamental question almost never asked:

Is this system well engineered—or does it merely appear to work?

The Industry’s Blind Spot

Software development suffers from a unique problem: we almost never get to compare two fundamentally different approaches to the same system.

• One system is built by Team A, using framework templates

• Another is built by Team B, using a strong conceptual model

Different teams, different timelines, different constraints.

So when a system “works,” we assume:

the approach must be valid

But we never see:

what that same system could have looked like with a better model

That absence of comparison creates a blind spot—one where “working software” is mistaken for “well-designed software.”

The Rise of Template-Driven Development

Frameworks like Spring Boot didn’t become dominant by accident.

They offer:

• immediate productivity

• standardized structure

• fast onboarding

They allow teams to produce output quickly—often without deeply understanding the domain.

And that’s where the shift happens.

Instead of asking:

What is the correct model of this domain?

Teams start asking:

Where does this go in the template?

At that point, development turns into something else entirely:

Stenography. Translating user stories into predefined technical slots.

The result:

• large amounts of integration code

• thin or absent domain logic

• systems that function—but are difficult to evolve

The Cost You Don’t See

Systems built on heavy frameworks don’t usually fail.

They degrade.

Not in obvious ways, but in how time and effort are spent.

At first, development feels fast:

• scaffolding is generated

• endpoints are wired

• persistence is handled

Features appear quickly.

But over time, a shift happens.

The system is no longer primarily about automating the business domain.

It becomes increasingly about maintaining the technical environment around it.

The Hidden Shift in Effort

In many enterprise systems, a large portion of engineering effort is spent on:

• upgrading frameworks (e.g. annual cycles in Spring Boot)

• adapting to breaking changes

• resolving dependency conflicts

• aligning with new conventions and best practices

• re-testing behavior that should not have changed

This is not business value.

It is tooling maintenance.

Over time, the ratio shifts:

Less effort goes into improving the domain.
More effort goes into keeping the system compatible with its own foundation.

In extreme cases, the majority of work is no longer about what the system does, but about what it runs on.

Integration Becomes the System

As frameworks evolve, systems accumulate:

• layers of adapters

• configuration overrides

• compatibility fixes

The result is a codebase where:

• most code connects things

• very little code expresses the domain

At that point:

The system is no longer a model of the business.
It is a network of integrations.

The Upgrade Trap

Modern frameworks evolve continuously.

Each upgrade promises:

• improvements

• performance gains

• new capabilities

But each upgrade also introduces:

• migration effort

• subtle behavioral changes

• renewed testing cycles

Individually, these seem manageable.

Collectively, they create a constant background load.

A system that was supposed to simplify development now requires continuous adaptation just to remain operational.

Loss of Focus

The most damaging effect is not technical—it’s directional.

When most effort is spent on:

• frameworks

• infrastructure

• compatibility

Then the business domain becomes secondary.

Teams stop asking:

How do we model this problem better?

And start asking:

How do we make this work within the framework?

At that point, the system is no longer driven by the domain.

It is driven by the tooling.

The Real Cost

This cost rarely appears in metrics.

It shows up as:

• slower feature delivery over time

• increasing effort for simple changes

• growing system fragility

• loss of clarity about what the system actually does

And most critically:

A large portion of engineering capacity is spent on work that does not move the business forward.

The Alternative: Start With the Model

There is another way to build systems—one that doesn’t start with frameworks or templates.

It starts with a different premise:

Software development is primarily a modeling activity.

Before writing code, you ask:

• What are the core responsibilities?

• Where does behavior belong?

• What are the invariants of the system?

From there, you build:

• rich domain objects that own behavior

• clear boundaries that prevent concern leakage

• explicit lifecycles that reflect real interactions

In such a system:

• objects are used, not orchestrated

• behavior is invoked, not assembled

• structure reflects meaning, not framework conventions

“But What About Wiring?”

A common assumption in enterprise development is that systems require extensive wiring:

• dependency injection

• service composition

• configuration graphs

But this is often a symptom, not a necessity.

When responsibilities are well-defined and localized:

• objects don’t need to be assembled dynamically

• behavior doesn’t need external orchestration

• lifecycle can be handled at clear boundaries

Instead of wiring a system together, you:

define objects that already make sense together

Infrastructure concerns—like persistence or messaging—can be handled through:

• decorators

• well-defined interaction boundaries

Not scattered across the system.

The result is not “no composition,” but:

composition that is internal, stable, and invisible

Why This Feels Slower (But Isn’t)

Taking time to understand the domain can feel like a delay.

But consider the alternative:

• building quickly in the wrong direction

• discovering mismatches later

• restructuring under pressure

It’s the difference between:

• planning a route before driving

• or heading “roughly east” and hoping to arrive

The first appears slower. The second is slower—just not immediately.

The Real Constraint

If this approach is so effective, why isn’t it the norm?

Because it depends on something rare:

Strong conceptual thinking

Framework-driven development scales because it:

• reduces decision-making

• standardizes structure

• works with uneven skill levels

Conceptual modeling does not:

• it requires alignment

• it requires discipline

• it requires engineers who can think in systems

So organizations optimize for:

predictable output

Instead of:

optimal design

The Resulting Illusion

This leads to a persistent illusion in the industry:

• Systems built with heavy tooling are seen as “modern”

• Systems built with strong models are seen as “overthinking”

Because one produces:

• immediate, visible progress

And the other produces:

• long-term structural integrity

But without a direct comparison, the difference remains invisible.

A Different Standard of Success

If we want to build sustainable systems, we need to change the definition of success.

Not:

“Does it work?”

But:

• How easy is it to understand?

• How localized is change?

• How much of the code reflects the domain vs integration?

Because ultimately:

A system that merely works today can become a liability tomorrow. A system that is well modeled continues to work—even as it evolves.

Closing Thought

Tooling is not the enemy.

But it becomes a problem when it replaces the very thing it was meant to support:

Engineering.

Frameworks can accelerate implementation. They cannot replace understanding.

And without understanding, we’re not engineering systems.

We’re assembling them—and hoping they hold.

Both involve creating something coherent out of many parts.
Both require understanding purpose before execution.
And both reveal a common mistake that appears surprisingly often in modern software development.

To see why, imagine two professionals: a ghostwriter and a house builder.

The Ghostwriter Version of Software Development

Imagine you hire a ghostwriter to write a book based on your ideas.

You send them fragments:

• a story about a childhood memory

• a chapter about leadership

• a few anecdotes about business

• a paragraph about innovation

• a repeated explanation of a concept you already mentioned earlier

A bad ghostwriter simply writes everything down exactly as provided.

The result is technically correct. The grammar is fine. The sentences are clear.

But the book becomes a mess:

• topics overlap

• concepts repeat

• arguments contradict each other

• the narrative jumps randomly between ideas

Nothing ties the material together into a coherent story.

The ghostwriter has focused on transcription, not authorship.

Unfortunately, software development is sometimes practiced in a very similar way.

A team receives a series of user stories:

• “Customers should be able to create orders.”

• “Orders can have discounts.”

• “Admins can modify customer data.”

• “Orders must be validated before submission.”

Each story is implemented somewhere in the codebase. A controller here, a service there, a validation rule somewhere else.

Every story is technically implemented.

But over time the system starts to show symptoms:

• business rules appear in multiple places

• behavior becomes inconsistent

• changes require touching many unrelated components

• nobody is entirely sure where certain logic belongs anymore

The system becomes the equivalent of the badly written book: a collection of fragments without a coherent narrative.

The problem is not coding skill. The problem is the absence of structure.

The House Builder Version of Software Development

Now imagine designing a wooden house.

But instead of starting with how people will live in it, the builders start with their tools.

The plumber places the bathroom where the pipes are easiest to install.

The electrician places the kitchen where wiring is convenient.

The carpenter builds bedrooms wherever the structure is simplest.

Each professional does excellent work.

The plumbing is perfect.
The wiring is flawless.
The construction is solid.

But when the house is finished, something feels very wrong.

The dining room is on the opposite end of the kitchen.
The shower is installed in the kitchen because the pipes were already there.
The bedrooms are nowhere near the bathroom.

Every part of the house is technically well built.

But the house does not work as a house.

No one began by asking the most important question:

How will people live here?

The same thing happens in software development when architecture is driven primarily by tools and technologies.

Discussions revolve around:

• frameworks

• infrastructure

• microservices

• deployment pipelines

• cloud platforms

All important tools.

But they are construction techniques, not design principles.

Without understanding how the system is supposed to behave as a whole, even the best tools can produce a system that is technically impressive but conceptually broken.

What’s Missing: Coherent Design

Both examples expose the same underlying problem.

The ghostwriter fails because they never discovered the story.

The house builders fail because they never understood the purpose of the house.

In software engineering, the equivalent is failing to understand the domain.

User stories describe fragments of behavior.

But if every story is simply implemented as-is, the system slowly loses coherence.

Engineering cannot start with implementation. It must start with understanding.

What activities exist in the domain?
What concepts matter?
What rules must always hold?
Where should responsibilities live?

Only when those questions are answered does the structure of the system begin to emerge.

Enter the Domain Model

This is where the domain model becomes essential.

A domain model acts as a responsibility localizer and logic contextualizer.

Instead of scattering behavior across the codebase, the model provides structure:

• concepts are represented explicitly

• rules live with the concepts they govern

• responsibilities have clear homes

When a new user story arrives, the question is no longer:

“Where should we add this piece of code?”

Instead the question becomes:

“What does this story mean for our understanding of the domain?”

Sometimes the answer is simple.

Sometimes it requires adjusting the model itself.

But the goal remains the same: preserve conceptual integrity.

Without that integrity, software inevitably turns into the badly written book or the badly designed house.

The Risk of AI

AI-assisted coding is incredibly powerful.

It can generate code, implement features, suggest refactorings, and remove enormous amounts of repetitive work. Used well, it is an enormous productivity accelerator.

But AI is strongest at local implementation.

It excels at doing exactly what it is asked: implementing a function, adding a feature, modifying an existing piece of code. In that sense it behaves very much like the literal ghostwriter who writes the paragraph that was requested, or the contractor who builds a perfectly constructed room.

What AI does not replace is modeling the domain.

It does not determine:

• what the core concepts of the system should be

• where responsibilities belong

• how rules should be structured

• how the system should reflect the purpose of the business

Those decisions require understanding intent and discovering structure. They are design activities.

AI can dramatically accelerate the technical execution of a system. But it cannot replace the need for coherent design.

Otherwise we risk the same outcomes as before: a technically correct book without a story, or a well-built house that no one can live in.

Conclusion

In an interesting way, the rise of AI coding tools highlights something that has always been true in software development.

Many teams have already been operating primarily at the level of feature implementation, while the deeper design work was often implicit, inconsistent, or missing entirely.

Custom software is essentially a one-off prototype. There is no reference design to compare it to. There is no second version of the same system built by another team. There is only one implementation: the one that ends up running in production.

That makes design mistakes difficult to spot early.

A book with a broken narrative may only reveal its problems once the entire manuscript is finished.
A badly designed house may only reveal its flaws once people try to live in it.

Software is no different.

Which is why the design phase — understanding the purpose of the system and shaping a coherent domain model — cannot be skipped.

The ghostwriter must understand the story.
The architect must understand how the house will be lived in.

And the software engineer must understand the domain before writing the code that brings it to life.

Level 1 — Getting the system to run

At this level the goal is straightforward:

• the application compiles

• the system deploys

• features behave as expected

• users can operate the software

If those conditions are met, the project is considered successful.

Most modern frameworks are extremely good at helping teams achieve this level. A stack such as Spring Framework provides a ready-made structure for building applications quickly: web infrastructure, dependency injection, persistence integration, configuration management, and more. With the right templates and tooling, teams can produce a working system in relatively little time.

Level 2 — Keeping the system economically evolvable

The second level is far harder.

Once the system has been running for several years, the real question becomes:

• Can developers still reason about the business rules?

• Can features be added without breaking existing behavior?

• Does the cost of change remain predictable?

This is the level where software must remain economically viable. The system must evolve along with the business without collapsing under its own complexity.

Most of the industry focuses almost entirely on Level 1, because Level 2 is much harder to see.

The Observability Problem

In many engineering disciplines, different designs can be compared directly.

Two airplane designs can be tested against each other. Two bridge designs can be analyzed under the same load conditions. Engineers can evaluate alternatives objectively.

Enterprise software is different.

Most systems are unique implementations of a specific business domain. A logistics system for one company will not be rebuilt several times with different architectures just to compare which approach works best.

Because of that, organizations rarely observe multiple competing implementations of the same domain.

There is no side-by-side comparison like:

System A — rich domain model
System B — procedural service architecture

running the same business processes for several years.

Instead there is only one system: the one that was built.

As a result, success is evaluated using the only clearly visible metric:

Does the application run?

If the answer is yes, the architecture is usually considered successful.

The Rise of the Software Factory

Over time, the industry optimized for what was easiest to measure: producing working applications quickly.

This led to the emergence of standardized software production lines.

Typical enterprise stacks often follow a very familiar structure:

controller
service
repository
database

Add REST APIs, containerization, messaging infrastructure, and often microservices, and a predictable pattern emerges.

Framework ecosystems reinforce this pattern. They provide conventions, templates, and project generators that make it easy to spin up new services quickly.

From an organizational perspective, this approach promises several advantages:

• developers can move between projects easily

• teams can scale rapidly

• systems follow familiar patterns

• onboarding new engineers becomes simpler

These promises are appealing, especially to organizations managing large engineering teams.

However, these advantages are rarely tested against alternative architectural approaches. Because most enterprise systems are built only once, there is no direct comparison showing whether a different design would actually have been more efficient or easier to evolve.

As a result, the perceived success of factory-style development often rests on a simple observation:

• The application runs

• Features are delivered

Without a comparable implementation built around a different architectural philosophy, it is difficult to see whether the chosen approach truly delivered its promised benefits.

The result is a development process that resembles a software factory: a standardized production line designed to produce working applications quickly.

Whether it produces the right kind of system for the domain is a different question entirely.

The Model T Problem

The logic behind this standardization is similar to the philosophy associated with Henry Ford and the Ford Model T.

The Model T revolutionized manufacturing through standardization. One of the famous ideas attributed to Ford was that customers could choose any color, as long as it was black.

This approach worked because the product itself was standardized.

Cars were produced for a broad market with relatively similar requirements.

Enterprise software is fundamentally different.

Each system represents a specific business domain:

• logistics operations

• insurance policies

• trading platforms

• healthcare workflows

These domains have very different requirements and behaviors.

In effect, each enterprise application needs a different type of vehicle.

Some domains resemble heavy trucks carrying complex transactional logic. Others behave more like high-performance machines, where performance and precision matter enormously. Some systems are small and lightweight.

Yet many development ecosystems attempt to solve all of them with the same architectural pattern — the equivalent of producing a Model T for every possible use case.

Why This Appears to Work

Despite the mismatch, the Model T architecture still appears successful.

After all, a Model T can still move forward. It can transport people and even carry small loads.

Similarly, standardized enterprise architectures can deliver features:

• endpoints respond to requests

• data is stored and retrieved

• workflows execute

From the outside, the application works.

Because organizations rarely build the same system twice with different architectures, they never see a direct comparison. There is no competing design demonstrating that the system could have been far simpler or easier to evolve.

As long as the application runs and delivers features, the architecture appears to perform as expected.

The Hidden Cost of Factory Style Development

The real cost of factory-style architectures emerges gradually and usually in two dimensions: effort and functional quality.

Effort: Why development gets slower over time

In factory-style systems, implementing new functionality tends to require roughly the same effort every time.

Every feature follows the same pattern:

controller
service
repository
integration logic

Because the architecture is primarily procedural, the system rarely accumulates reusable domain behavior. Each feature often introduces new service logic rather than building upon existing concepts.

As the system grows, the situation frequently worsens:

• similar logic appears in multiple services

• developers must read many parts of the system to understand behavior

• debugging requires tracing through multiple layers and integrations

• knowledge transfer becomes difficult

The effort required to implement new functionality often remains constant or even increases over time.

Function-driven systems behave very differently.

When a system evolves around a coherent domain model, the model itself becomes a growing knowledge base of the business. Domain objects accumulate responsibilities and reusable behavior.

As the model matures:

• new features often extend existing objects

• behavior is reused rather than reimplemented

• developers can understand the system by understanding the model

Knowledge transfer becomes easier because the model tells the story of the application.

Debugging is also simpler. When rules live in their responsible objects, it becomes immediately clear where behavior originates. Developers do not need to search across multiple services implementing slightly different versions of the same logic.

Over time, the effort required to add functionality tends to decrease, because the model provides increasing leverage.

Quality: One version of the truth

Factory-style architectures often distribute business rules across multiple services.

It is common to find logic that is similar but not identical in different places:

• slightly different validation rules

• small variations in calculations

• edge cases handled in one service but not another

These inconsistencies are rarely intentional. They appear gradually as new features are implemented independently.

The result is a system with multiple interpretations of the same business rule.

Function-driven systems address this differently.

Each business rule belongs to the object responsible for that concept. The rule has one canonical implementation.

If a system contains an Order concept, the logic related to orders lives with the Order object. If there is pricing logic, it belongs to the pricing model.

This creates a single version of the truth.

Rules are not scattered across services or hidden inside orchestration layers. They are located where the business concept itself lives.

This greatly reduces contradictions and makes the system far easier to reason about.

The Engineering Principle

Enterprise systems should be function-driven rather than tool-driven.

Architecture should begin with understanding the domain:

• the concepts involved

• the relationships between them

• the rules that must remain consistent

Only after that understanding emerges should tools and frameworks be introduced to support the system.

Tools are valuable when they solve real problems in the running application:

• persistence

• messaging

• scaling

• reliability

But they should not dictate the structure of the domain model.

Why Rich Domain Models Help

A function-driven system begins with the domain model, not with architectural patterns or infrastructure.

Instead of starting with decisions like:

• microservices

• event-driven architecture

• CQRS

• messaging platforms

development begins with understanding the domain itself.

The first goal is to model the core concepts and their responsibilities.

Typical objects might represent concepts such as:

• Order

• Customer

• Shipment

• Invoice

These objects contain the behavior that defines the business logic.

At this stage, the focus is entirely on implementing the core functionality of the application.

Infrastructure concerns are introduced only when they become necessary.

For example:

• persistence is added when data must be stored

• messaging appears when asynchronous coordination is required

• scaling mechanisms appear when load actually demands them

In practice, many enterprise systems never reach the scale that requires complex distributed architectures.

For the majority of applications, a well-designed domain model within a cohesive system is entirely sufficient.

Only when real operational constraints appear should the architecture evolve technically.

This approach keeps the system aligned with the domain while avoiding premature technical complexity.

The result is software that grows organically around the business model, rather than being constrained by predefined architectural templates.

Closing Thought

TThe software industry has become extremely good at producing applications that run.

Frameworks, templates, and standardized stacks make it possible to build complex systems faster than ever before.

But enterprise software is not a short-term product. It is a long-lived system that must evolve together with the business.

Designing such systems requires something different from a software factory. It requires starting with the domain, building a coherent model, and letting the architecture grow from the problem instead of from the tools.

Otherwise we keep producing the same solution for every problem:

another black Model T.

The problem with that approach is not aesthetic. It is economic.

When the architecture does not match the domain, the mismatch shows up in three places:

• more engineering effort to implement and understand functionality

• higher long-term costs as development slows and operational complexity increases

• more fragile systems where business rules are scattered and difficult to reason about

In other words, the wrong architectural vehicle does not merely look inelegant — it makes the system harder and more expensive to operate for the rest of its lifetime.

Long-lived enterprise software requires something better than a one-size-fits-all production line.

It requires architectures that are designed around the domain they serve.

You can memorize frameworks, quote architecture patterns, and repeat industry “best practices.” After a few years, it becomes easy to sound like an expert.

But none of that proves someone is thinking like an engineer.

The real signal appears the moment their ideas are questioned.

Real software engineers welcome scrutiny.
Weak engineers resist it.

That difference sounds subtle — until you see its consequences on the systems they build.

Engineering is not about defending ideas.
It’s about breaking them before reality does.

Engineering Is Adversarial — Against Your Own Ideas

Every engineering discipline assumes designs are wrong until proven otherwise.

Bridges are stress-tested.
Aircraft parts are pushed to failure.
Mechanical designs go through brutal review cycles.

The goal is simple: find weaknesses early, when they’re cheap to fix.

Software should work the same way.

Design discussions and architecture reviews exist to expose flaws before they reach production.

Strong engineers instinctively understand this.

When someone challenges a design, they respond with curiosity:

“Good point. Let’s walk through that scenario.”

Every challenge is free stress-testing of the idea.

The Moment Engineering Turns Into Dogma

The opposite mindset is easy to spot. Ask a simple “why” question about a design, and the response sounds like:

• “Everyone does it this way.”

• “That’s the best practice.”

• “That’s the standard architecture.”

• “That’s how the framework expects it.”

Notice what’s missing: reasoning, trade-offs, context — replaced entirely by authority.

Dogma is attractive because it removes responsibility. If a rule exists, you can apply it everywhere without thinking.

But real systems are messy. Constraints differ. Scale differs. Failure modes differ. Engineering requires reasoning. Dogma replaces thinking with imitation.

Why This Matters

This difference shapes the systems teams build.

Teams that welcome scrutiny produce software that is:

• simpler

• easier to modify

• resilient to edge cases

• understandable by new engineers

Teams that avoid scrutiny accumulate:

• accidental architecture

• unnecessary abstraction layers

• rigid patterns nobody understands

• rules that exist only because “that’s how we do it here”

Over time, these systems become fragile. Ironically, teams most confident in their “best practices” often maintain the most brittle codebases.

The Quiet Signal

Strong engineers share one surprising trait: they are comfortable being wrong.

Not because they lack confidence, but because they understand: ideas improve under pressure.

If a flaw is pointed out in a discussion, it’s removed before it reaches production. That is not a loss. That is engineering at work.

The Real Difference

Weak engineers defend solutions.
Strong engineers investigate problems.

The difference shows up in small moments:

• One asks, “Why are we doing this?”

• The other says, “Because that’s the standard.”

• One explores trade-offs.

• The other quotes rules.

• One treats ideas as hypotheses.

• The other treats them as territory.

Over time, the systems these two mindsets produce look very different.

The Most Dangerous Engineer on a Team

The biggest risk is not the junior developer who makes mistakes, nor the architect who experiments too much.

It’s the engineer who cannot be questioned.

They will:

• defend ideas with authority, not reasoning

• tell you, “This is just how framework X works”

• repeat dogma instead of analyzing trade-offs

• stop discussions before flaws are exposed

The systems they leave behind look solid at first. Layers of rules, patterns, and abstractions give the illusion of control. But underneath, every flaw they refused to discuss becomes technical debt, fragile modules, and unexpected outages.

The “dangerous engineer” doesn’t intend to fail. They just protect their ego over the system. Every skipped discussion, every dismissed critique, every “because we’ve always done it this way” is a seed of future problems.

By contrast, engineers who welcome scrutiny quietly build resilience. They treat questions as free stress tests, fix flaws before production, and teach teams to reason, not obey.

One Final Signal

Ask yourself this next time you discuss a design or talk about implementation:

• Does this engineer invite questions, or do they shut them down?

• Do they explain why a decision was made, or do they quote rules?

• Are they curious about alternatives, or are they protecting territory?

The answers tell you everything you need to know.

Weak engineers defend solutions.
Strong engineers investigate problems.

The strongest engineers don’t just write code — they engineer thinking itself.

We select a set of user stories, implement them in a sprint, verify the new functionality, and move on to the next set. Each sprint adds something. The system grows feature by feature.

This works well — especially in the beginning.

The first stories are straightforward. The logic is easy to follow. The team still remembers where things live. Tests pass. Velocity is stable.

Nothing appears wrong.

The Nature of Additive Development

This way of working leads to what we can call additive development.

Each story adds behavior somewhere in the system:

• A new condition in a service.

• An extra validation in a controller.

• A new branch in an existing method.

• A special case layered on top of an old one.

Individually, these changes are reasonable. They solve the story at hand. They pass the tests written for that story.

But over time, something subtle happens.

Behavior becomes distributed.
Rules are implemented in different places.
Overlapping requirements are handled locally.
Old logic is adjusted without revisiting the bigger picture.

The system keeps working — but each sprint demands more effort to ensure nothing breaks. What was easy at sprint three can take hours of tracing, testing, and guesswork at sprint thirty. This is not about elegance; it is about operational risk.

Documentation Does Not Solve This

You can document rules.

You can describe processes.

You can maintain diagrams.

But documentation does not enforce behavior.

Only code does.

If the code does not have a single authoritative place where business rules live, then documentation becomes commentary on a system that may already behave differently in different execution paths.

That is not a communication issue.
That is a structural issue.

What Is a Rich Domain Model?

A rich domain model takes a different approach.

In a rich domain model:

• Business behavior lives together with the data it governs.

• Rules are owned by the model, not by surrounding services.

• Objects expose meaningful operations instead of raw setters.

• Invariants are centralized and protected.

Instead of treating domain objects as passive data structures, they become active representations of the business.

A rich domain model is a single, coherent expression of how the business behaves.

There is one authoritative place where rules live. One place where state changes are defined. One place that describes what is allowed and what is not.

Additive vs Analytical Development

The real difference appears when new stories arrive.

In additive development, the implicit question is:

Where can I implement this story?

In a rich domain model, the question becomes:

What does this story mean for our understanding of the domain?

That shift changes everything.

New requirements are not simply attached somewhere convenient. They are analyzed in relation to the existing model. Do they fit the current rules? Do they contradict an invariant? Do they reveal that our understanding was incomplete?

Sometimes the model absorbs the change easily.
Sometimes the model itself must evolve.

But the evolution happens in one central place.

Rich domain models are not difficult because they are complex. They are difficult because they require the team to take responsibility for understanding the domain instead of just implementing requirements.

That responsibility forces clarity.

Contradictions surface early.
Ambiguities become visible.
Hidden assumptions are challenged.

Why Development Becomes Easier Over Time

A common misconception is that rich domain models slow development down.

In practice, the opposite tends to happen.

When the model is coherent and well-shaped:

• The logic for new stories is often already partially present.

• Behavior has a clear home.

• You do not search the entire codebase to find where rules might live.

• You do not duplicate validations in multiple layers.

• You are not afraid to change existing code.

Each sprint deepens the same model.

In additive systems, every sprint adds more places where logic might live. In rich systems, every sprint strengthens the same conceptual center.

Over time, additive systems become harder to extend.
Rich systems become easier to reason about and faster to extend and maintain.

The difference is not visible in the first few sprints. It becomes visible after months and years.

But rich modeling is not automatic. It is hard because it requires engineers to think in terms of behavior, not just features. Teams without this skill may fail to capture the benefits, or worse, create pseudo-rich models that combine the worst of both worlds: scattered behavior and extra complexity.

The Real Benefit

The greatest advantage of a rich domain model is not technical elegance.

It is clarity.

When business behavior is centralized and explicit, the software becomes a mirror of the domain. If two requirements contradict each other, the model makes that tension visible. The team can address it before the contradiction becomes embedded in production logic.

The system does not merely accumulate features.
It accumulates understanding.

And in long-lived software — the kind that represents real business processes and institutional knowledge — that difference determines whether the system remains an asset or slowly turns into a burden.

There is something undeniably compelling about modern AI code generation.

You describe a feature.
It scaffolds the controllers.
It writes the repository layer.
It generates DTOs, tests, migrations, and configuration.

What used to take weeks can now appear in minutes.

For greenfield projects especially, the acceleration feels almost unfair. A single developer can prototype at a pace that previously required a small team. Refactoring feels assisted rather than manual. Exploration becomes interactive.

If you measure success by initial velocity, AI looks like a revolution.

And in many contexts, it is.

But velocity is only one axis of software quality.

The real question is not:

“Can AI generate my application?”

It clearly can.

The real question is:

“What happens after generation?”

That is where engineering discipline becomes decisive.

1. The Licensing Risk

This topic tends to be exaggerated and underestimated at the same time.

What is the concern?

AI models are trained on large corpora of public and licensed code. That creates two potential risks:

1. Inbound copyright contamination
   The model might generate code substantially similar to licensed material.

2. Outbound trade secret exposure
   You might paste proprietary logic into a cloud system without adequate contractual protection.

The first risk is statistically low but non-zero.
The second risk depends entirely on how and where you use the tool.

Practical mitigation

Treat AI output like third-party external code:

• Review it rigorously.

• Refactor it into your own architectural style.

• Avoid accepting large structured blocks verbatim.

• Run automated license scanning in CI.

• Avoid pasting core proprietary algorithms into consumer-tier tools.

In most commercial environments, this is manageable with policy and review discipline. It is not a reason to avoid AI entirely — but it is a reason to use it intentionally.

2. The Loss of Engineering Control

This is the more serious risk.

AI optimizes locally.

It does not:

• Maintain architectural invariants across months of development.

• Enforce consistency of abstraction boundaries.

• Protect aggregate integrity.

• Guard against semantic drift in business rules.

If a developer merely accepts generated code, they are no longer designing the system. They are curating output.

Over time this leads to:

• Inconsistent abstractions

• Leaky layers

• Duplication of logic

• Hidden coupling

• Architectural entropy

The system “works,” but its internal coherence degrades.

And once that coherence is gone, refactoring cost increases non-linearly.

AI accelerates code production.
It does not automatically accelerate architectural reasoning.

If that reasoning is outsourced, engineering control erodes.

3. Additive Development Without a Domain Model

AI makes additive development dangerously easy.

A user story arrives:

“As a user, I want X.”

The developer prompts:

“Implement X in Spring Boot.”

The feature appears. It compiles. It passes basic tests.

Next sprint, another story.
Another prompt.
Another isolated feature.

What is missing?

• No shared domain language.

• No explicit invariants.

• No aggregate boundaries.

• No semantic model anchoring decisions.

• No systemic review of how new logic interacts with existing rules.

The application grows by accumulation, not by modeling.

Each user story is implemented in isolation.

This works surprisingly well in simple domains.

It fails gradually — and then suddenly — in complex domains.

Conflicting business logic emerges.
Edge cases multiply.
Validation rules scatter.
Performance assumptions break.

The problem is not that AI wrote the code.

The problem is that no one owned the conceptual integrity of the system.

AI amplifies additive development because it reduces the friction that previously forced engineers to think before coding.

When implementation becomes trivial, modeling must become deliberate.

4. Where AI Truly Excels

It would be intellectually dishonest to ignore where AI is extraordinarily effective.

AI code generation is highly valuable for:

• Refactoring suggestions

• Syntax transformations

• Exploratory prototyping

• Learning unfamiliar APIs

• Discussing domain trade-offs

• UX best practices and semantic HTML scaffolding

Notice what is absent here:

Not “boilerplate.”
Not DTO factories.
Not mindless CRUD scaffolding.

Those patterns often signal the absence of a meaningful domain model in the first place.

AI shines when it augments cognition — not when it replaces modeling.

In low-complexity systems, the development approach often matters less. If logic is shallow and bounded, AI-generated solutions may be entirely sufficient.

The danger increases as:

• Domain complexity increases

• Invariants become subtle

• Concurrency becomes relevant

• Transactions carry business meaning

• Regulatory constraints appear

• Performance characteristics matter

The more your system embodies meaning rather than mechanics, the more indispensable human modeling becomes.

5. AI as an Amplifier, Not a Replacement

AI is a force multiplier.

It accelerates:

• Exploration

• Refactoring

• Learning

• Iteration speed

It does not replace:

• Judgment

• Modeling

• Trade-off analysis

• Responsibility

• Architectural ownership

A healthy pattern looks like this:

1. Model the domain deliberately.

2. Define invariants explicitly.

3. Decide architectural boundaries consciously.

4. Use AI to accelerate implementation within that framework.

5. Review and reshape generated output.

6. Maintain systemic coherence.

An unhealthy pattern looks like this:

1. Prompt.

2. Read and Learn.

3. Adapt where necessary.

4. Repeat.

The difference is not in the tool.
It is in who remains accountable for the system’s integrity.

6. AI Is Not a Substitute for Engineering Expertise

There is one final misconception worth addressing.

AI is not a gap-filler for missing engineering expertise.

It can accelerate someone who already understands:

• Abstraction boundaries

• Invariants

• Transactional semantics

• Coupling and cohesion

• Long-term maintainability

But it cannot compensate for the absence of that understanding.

Framework knowledge is not engineering expertise.
Pattern memorization is not engineering expertise.
Syntax fluency is not engineering expertise.

Engineering expertise is, among other things:

• The ability to model a domain precisely.

• The discipline to protect invariants.

• The skill to keep abstractions aligned with business meaning.

• The judgment to decide what not to build.

• The restraint to prevent accidental complexity.

• The awareness to detect when the model is drifting.

AI can generate structures.
It cannot guarantee conceptual integrity.

If a developer lacks domain modeling skills, AI will not fix that gap.
It will often amplify it — by making it easier to produce more code faster.

And more code without a coherent model does not create better systems.
It creates faster entropy.

Conclusion

AI is a remarkable accelerator.

But acceleration without direction is drift.

AI amplifies the strengths of a disciplined engineer.
It also amplifies the weaknesses of an undisciplined one.

The real competitive advantage in the age of AI is not typing speed.

It is the ability to design systems whose internal logic remains coherent as they evolve.

That remains a deeply human responsibility.

It fails because ideas are not tested against reality early enough.

One of the most powerful feedback mechanisms in software development is not architecture review, not UML diagrams, and not planning sessions.

It is writing code.

Actual coding is not merely implementation.
It is a continuous validation of the design against the domain.

When that feedback loop is weakened, design drifts away from reality. When it is removed entirely, software starts to “run in PowerPoint.”

AI-assisted development increases this risk dramatically.

Coding Is a Feedback Mechanism

There is a common misconception that coding is a mechanical activity — translating design into syntax.

In reality, coding is where design meets constraint.

When implementing a rich domain model:

• Edge cases surface.

• Invariants become harder than expected.

• Responsibilities feel misplaced.

• Names no longer fit.

• Assumptions break.

Every friction point during implementation is feedback:

• The model might be incomplete.

• The model might be wrong.

• The abstraction might be too shallow.

• The business concept might be misunderstood.

Writing code forces the developer to confront the domain at a granular level.

This confrontation produces learning.

Coding builds understanding as much as it builds functionality.

The Domain Enables Functionality — It Is Not the Same

A common failure mode in story-driven development is conflating the domain with required behavior.

But the domain is not the list of user stories.

The domain is the conceptual structure that makes those stories possible.

Describing a business domain purely by its features is like describing an animal only by its behavior:

• “It runs.”

• “It eats.”

• “It sleeps.”

Those are outputs.

They do not explain structure.

A domain model is the anatomy.
Stories are movements.

If the anatomy is wrong, movements will conflict.

Modeling Is Iterative Learning

In simple domains, the gap between initial model and actual domain may be small.

In complex domains, it rarely is.

Each new functional story reveals something:

• A missing state.

• An implicit rule.

• A conflicting assumption.

• An incorrect boundary.

A well-structured domain model absorbs that feedback.
It evolves deliberately.

If coding is happening, this evolution is continuous.

The model is constantly tested against real constraints.

Without coding involvement, that feedback loop weakens.

The Ivory Tower Effect

Ivory tower software development occurs when:

• Strategic or senior decisions are made about detailed design,

• Without direct involvement in implementation,

• And without experiencing the friction of coding.

At that point, design decisions are evaluated abstractly rather than empirically.

Ideas look clean in diagrams.
They look coherent in slide decks.

But code exposes reality:

• What is awkward?

• What is redundant?

• What does not compose?

• What contradicts existing invariants?

Without that confrontation, design becomes speculative.

When feedback from implementers is ignored — especially when authority is hierarchical — the disconnect grows.

This is the real-world version of the “runs in PowerPoint” meme:

The system appears coherent conceptually, but its operational behavior tells a different story.

AI-Assisted Development: Removing the Friction

AI-assisted development changes the dynamic in a subtle but profound way.

Traditionally, flawed design reveals itself through implementation pain.

With AI:

• Complex logic can be generated quickly.

• Edge-case handling can be synthesized.

• Boilerplate friction disappears.

• Implementation obstacles shrink.

The system “works.”

But friction is not just an inconvenience.
It is feedback.

If AI absorbs that friction:

• The developer experiences less resistance.

• The design is challenged less directly.

• Structural weaknesses can be papered over with generated complexity.

AI is extremely good at making something function.

It is not inherently responsible for questioning whether the underlying domain model is coherent.

If the model is weak, AI will happily implement increasingly elaborate logic around it.

This is where divergence accelerates.

Where Do the Lessons Go?

In traditional coding:

• A developer struggles with an awkward method.

• Realizes responsibility is misplaced.

• Refactors the model.

• Simplifies behavior.

• Strengthens invariants.

That learning is embodied in the design.

With prompt-driven development:

• The developer asks for feature X.

• The AI produces working logic.

• Tests are generated.

• The story is complete.

But where did the design feedback go?

If the developer does not deliberately step back and re-evaluate the model, no automatic mechanism ensures that lessons learned during implementation are incorporated into domain structure.

AI can generate working code faster than teams can reflect on model integrity.

Velocity increases. Reflection often does not.

Preventing Divergence Across Stories

This becomes especially critical for core concepts like Order.

Across multiple user stories:

• Orders gain new states.

• Exceptions accumulate.

• Special-case transitions appear.

• Cross-cutting flags are introduced.

If each story is implemented additively — especially via prompts — divergence becomes likely:

• Different stories interpret the same concept differently.

• Invariants become conditional.

• The model becomes a collection of patches.

To prevent this:

1. Every new story must begin with model validation:

   • Does the current Order model still represent reality?

   • Are its invariants still coherent?

   • Does the lifecycle still make sense?

2. Implementation friction must be examined, not bypassed.

   • If something feels awkward, the model may be wrong.

3. AI must be used to refine models — not only extend behavior.

If stories accumulate faster than the model evolves, divergence is inevitable.

The Core Risk

Ivory tower development disconnects design from implementation reality.

AI-assisted development risks disconnecting implementation from conceptual learning.

Both weaken the feedback loop between:

• Model

• Code

• Domain understanding

When that loop weakens, conceptual drift accelerates.

And when core concepts drift, conflicting business logic is only a matter of time.

AI as Amplifier — Not Villain

AI is not the enemy here.

It is an amplifier.

And amplification works in both directions.

In environments where teams already treat coding as a feedback mechanism — where friction triggers reflection and models evolve deliberately — AI becomes a powerful collaborator. It accelerates exploration, surfaces alternatives, fills knowledge gaps, and acts as an always-available discussion partner.

But in environments where development is already procedural — where stories are implemented sequentially without structural re-evaluation — AI does not change the underlying dynamic.

It scales it.

If the dominant habit is:

• Add a story

• Make it pass

• Move on

Then AI simply increases throughput.

The structural weakness was already there.
AI makes it faster, cheaper, and less visibly painful.

The real danger is not AI.

The danger is bypassing reflection at scale.

AI removes mechanical friction.
That is progress.

But if the organization never had a practice of responding to conceptual friction, AI ensures that absence compounds silently.

It does not introduce drift.
It accelerates whatever discipline — or lack of discipline — already exists.

The Real Question

A reasonable counter-argument is:

“If the stories work, why does model divergence matter?”

Individually, they do work.

Each story passes its tests.
Each feature behaves correctly within its own context.

The problem is that stories are not independent.

They operate on shared concepts, shared data, and shared invariants.

In a real system — whether a distributed microservice landscape or a monolith — every story modifies the same underlying domain.

And when each story subtly reshapes that domain without structural re-evaluation, coherence erodes.

The result is not immediate failure.

It is unpredictability.

Cancellation rules interact strangely with refund logic.
Fraud review states conflict with shipment transitions.
Administrative overrides bypass invariants assumed elsewhere.
Flags introduced for one use case leak into others.

Nothing is obviously broken.

But behavior becomes conditional, context-dependent, and difficult to reason about.

The system no longer behaves as a unified model - It behaves as accumulated exceptions.

A rich domain model exists precisely to prevent this.

It ensures that integration is intentional — not accidental.

It provides a single, coherent definition of:

• What an Order is

• What states are valid

• What transitions are legal

• What invariants must always hold

Without that coherence, stories remain locally correct but globally inconsistent.

And that inconsistency compounds.

Final Thought

Software rarely collapses because individual features fail.

It becomes fragile because the relationships between features stop making sense.

Local correctness is easy to achieve.

Global coherence is not.

A system can pass every story-level test and still drift into unpredictability — not because the code is broken, but because the underlying model has fragmented.

When shared concepts evolve without deliberate validation, integration becomes accidental.

And accidental integration always produces conditional behavior, hidden coupling, and contradictory assumptions.

Coding is the mechanism that keeps this from happening.

It forces ideas to confront constraints.
It exposes where invariants strain.
It reveals when abstractions no longer hold.

That confrontation is not an inconvenience.

It is the stabilizing force of design.

AI does not eliminate that force — but it can soften it.

When friction is absorbed automatically and stories ship without structural pause, learning decouples from implementation.

Velocity rises.
Reflection does not necessarily follow.

The result is not immediate failure.

It is gradual loss of predictability.

And predictability is what makes software reliable, extensible, and economically sustainable.

AI will continue to increase throughput.

The question is whether teams will increase structural discipline at the same pace.

Because in the end, software does not degrade when ideas are ambitious.

It degrades when feedback is ignored.

And the most important feedback loop in software development is still the one between:

Model.
Code.
Reality.

Preserve that loop — and AI becomes a multiplier of clarity.

Neglect it — and AI becomes a multiplier of drift.

When software evolves story by story, business rules accumulate. Each new feature works in isolation. Tests pass. Code reviews succeed. Deployment looks stable.

And yet, over time, the system’s behavior becomes contradictory.

The root cause is structural: business rules are implemented without a mechanism that forces them to reconcile.

The Structural Risk of Story-Driven Development

Story-driven development optimizes for delivering isolated behavior:

• A story defines a scenario.

• A service implements that scenario.

• Tests verify the scenario.

This process is efficient. It is also structurally dangerous in larger systems.

User stories describe cases.
They do not define invariants.

Consider an Order concept:

• Closed orders cannot be modified.

• VIP customers may modify any order.

• Orders older than 30 days cannot be changed.

Each rule is valid. Each can be implemented cleanly inside a dedicated service.

But when rules are implemented procedurally — distributed across services — nothing forces them to converge. Each addition extends the system laterally.

The result is an accumulation of overlapping constraints without reconciliation.

Fat Services and Distributed Authority

In procedural, service-centric systems:

• Data structures are passive.

• Services orchestrate and mutate state.

• Business rules are embedded in workflows.

• Multiple services modify the same conceptual entity.

There is no single authority over state transitions.

When a new rule is introduced, developers must manually discover where related logic already exists. Conflict detection depends on:

• Personal experience

• Code search

• Team memory

• Review discipline

As the system grows, this becomes untenable.

The number of overlapping scenarios increases. The surface area of potential rule interaction expands. But the architecture provides no increasing structural protection against contradiction.

Conflicts are not prevented. They are postponed.

Fragmentation Does Not Remove Conflict

A common reaction to growing complexity is to split logic into smaller, independent services.

Locally, this feels like improvement:

• Each service becomes focused.

• Code appears cleaner.

• Responsibilities seem separated.

But business rules do not stop interacting simply because code is divided.

Instead of colliding inside a single module, contradictory rules now manifest across services. The conflict moves from design time to runtime.

The consequences appear in persisted data:

• Invalid state combinations

• Inconsistent status transitions

• Manual reconciliation processes

• Compensating logic layered on top of earlier logic

Once inconsistent production data exists, repair is no longer a refactoring problem. It becomes an operational problem. Historical correctness may be lost. Migration may be partial. Business trust may be affected.

Avoiding design friction early often produces operational friction later — at a much higher cost.

The Testing Illusion

Automated tests do not automatically protect against this failure mode.

Story-driven development naturally produces story-scoped tests:

• Given a scenario

• When an action occurs

• Then the expected outcome is produced

These tests confirm that each individual requirement behaves as intended.

They do not confirm that all rules concerning a concept remain mutually consistent.

As stories accumulate:

• The test suite grows.

• Coverage metrics improve.

• Confidence increases.

But what increases is scenario coverage — not invariant coverage.

All tests can pass while the system violates a broader constraint that was never explicitly modeled.

Testing mirrors structure.
If invariants are not structurally centralized, they are rarely centrally tested.

What Is Missing: Invariant Boundaries and Model Validation

Business rules are constraints over allowed state transitions.

To prevent contradiction, those constraints must converge at a single structural boundary.

But something even more fundamental is often missing:

Before implementing a new story, the domain model itself must be validated.

In procedural, story-driven development, implementation typically begins like this:

• Identify the service to extend.

• Add logic for the new scenario.

• Add tests for the new behavior.

The current model is assumed to be sufficient.

In a domain-centered approach, implementation begins differently:

1. Does the current model accurately represent the business concept?

2. Does the new requirement fit within the existing invariants?

3. If not, what must change in the model itself?

The model is not an implementation detail.
It is the core definition of the business domain.

If the business expands, the model must be re-evaluated.

If a new rule cannot be added without bypassing existing constraints, that is not an inconvenience — it is a signal:

• Either the new requirement conflicts with established invariants,

• Or the model is incomplete or incorrectly structured.

In both cases, the model must change before behavior is extended.

Behavior Must Live with Responsibility

When behavior is implemented in services, it is possible to extend functionality without confronting the underlying concept.

When behavior lives with the domain model, that is no longer possible.

Instead of multiple services independently mutating an Order, the concept itself owns its transitions:

• Order.modify()

• Order.close()

• Order.reopen()

Every rule affecting order state must pass through the same boundary.

Contradictory requirements cannot be implemented in isolation. They must reconcile inside the model.

This creates deliberate friction.

That friction is the warning mechanism.

Testing also changes:

• Tests target allowed and forbidden state transitions.

• Invariants become explicit and enforceable.

• The concept, not the service flow, becomes the primary test subject.

The model becomes the consistency mechanism.

Why This Becomes Critical in Larger Systems

In small systems, informal coordination may suffice.

In larger systems:

• Teams change.

• Context is lost.

• Features overlap.

• Edge cases multiply.

• Historical decisions fade.

Relying on human memory to prevent contradictory business rules does not scale.

If the architecture does not enforce reconciliation structurally — and if every new story does not begin by validating the domain model — contradiction will accumulate silently until it appears in production data.

AI-Assisted Story Development: Acceleration Without Reconciliation

AI-assisted development amplifies the structural risks described above.

Large language models are particularly effective at:

• Implementing a described scenario.

• Generating service-layer logic.

• Producing matching tests for that scenario.

• Extending existing workflows with minimal friction.

Given a prompt such as:

“Add support for VIP overrides.”

An AI system will generate correct, locally consistent code.

It will also generate tests that confirm the behavior works as described.

But AI operates at the level of the prompt.

It does not maintain an internal, evolving model of the business domain unless explicitly guided to do so. It does not spontaneously validate global invariants across the entire system. It optimizes for satisfying the current instruction.

As a result:

• Feature velocity increases.

• Additive logic accumulates faster.

• Story-scoped correctness improves.

• Cross-story reconciliation weakens.

In human-only development, conceptual drift happens gradually.

With AI-assisted story implementation, drift can occur at machine speed.

The danger is subtle:

Because each individual change appears correct and well-tested, the system gives a strong illusion of health — even as its conceptual coherence erodes.

Without explicit invariant boundaries and model validation, AI becomes a powerful accelerator of divergence.

The technology is not the problem.
The absence of structural reconciliation is.

When the model is the primary artifact, AI can assist in refining it.
When stories are the primary artifact, AI amplifies fragmentation.

Conclusion

Procedural, service-centric, story-driven development makes it easy to implement new requirements quickly. It does not make it easy to preserve conceptual integrity.

By distributing business rules across workflows instead of consolidating them around responsibility boundaries, it removes the structural warning signals that reveal contradiction early.

Preventing conflicting business logic requires:

• Explicit invariant boundaries

• Central ownership of state transitions

• Model validation before implementation

• Tests that verify constraints, not just scenarios

Without these, correctness depends on memory and discipline.

With them, consistency becomes structural rather than accidental.

That framing misses something fundamental.

ACID was never primarily about storage engines. It was about correctness: how a system preserves meaning while work is performed. Early transactional theory, notably articulated by Jim Gray, treated transactions as units of state transformation that preserve invariants. In other words: something happens, and the system remains valid.

Stripped of implementation detail, ACID says something almost trivial:

A piece of business logic either succeeds or fails.

Nothing more.

This article proposes a simple idea:

The ease with which you can express ACID semantics is a useful litmus test for system simplicity.

Not simplicity as “few services” or “small codebase”, but simplicity as clear, local, and comprehensible business behavior.

ACID Without Mysticism

Before discussing architecture, it helps to de-dramatize ACID.

At a semantic level:

• Atomicity → The operation completes or it does not.

• Consistency → Business rules remain true.

• Isolation → Concurrent operations do not observe nonsense.

• Durability → Completed decisions are not forgotten.

These are not database tricks.

They are descriptions of how real-world business actions are expected to behave.

When someone places an order, the business does not conceptually accept “half an order”.
When money is transferred, the organization does not consider “eventually maybe transferred” a meaningful state.

ACID is simply the smallest vocabulary that describes this expectation.

Cheap ACID Boundaries

If a piece of business logic:

• Executes in one place

• Operates on a coherent model

• Owns its own invariants

then drawing an ACID boundary is almost boring.

Begin work.
Perform logic.
Commit or rollback.

This is what we can call a cheap ACID boundary.

Cheap not in licensing cost.
Cheap in reasoning cost.

There is one execution context.
One authority over state.
One moment where success or failure is decided.

In such a setup, a relational database is a natural storage fit—not because it “creates correctness”, but because it can mechanically record an already clear decision.

The database is not the source of rigor.

The model is.

Essential Complexity and Visibility

Fred Brooks famously distinguished between:

• Essential complexity – inherent to the problem.

• Accidental complexity – introduced by the solution.

Business rules, invariants, and transactional boundaries are essential complexity. They exist whether we like it or not.

When essential complexity is:

• Explicit

• Local

• Visible

a business operation can be understood as a single unit of intent.

Once that unit exists, ACID semantics follow naturally.

Not as an architectural goal.
Not as a framework feature.
But as a consequence.

When ACID Becomes “Hard”

ACID usually becomes “hard” only after something else happened first.

Typically:

• Business rules are split across services

• State ownership is divided

• Invariants are enforced in multiple places

Now a single business operation no longer has a single center.

At that point:

• Atomicity becomes choreography

• Consistency becomes convention

• Isolation becomes probabilistic

• Durability becomes replicated folklore

ACID did not become complex on its own.

The business concept was fragmented.

The cost increase is secondary.

The Litmus Test

For any business operation, ask:

• Where is the moment that decides success or failure?

• Where are the invariants enforced?

• Who owns the truth of this operation?

If these questions have clear, local answers, ACID will be easy.

If the answers involve:

• Multiple services

• Multiple databases

• Multiple asynchronous hops

then ACID will be expensive.

Not because ACID is outdated.

But because the system no longer has a simple place where “this either worked or it didn’t” can be stated.

That is the litmus test.

Relational Databases and the Boring Path

Relational databases often appear in this discussion, and that is not accidental.

They provide:

• Transactions

• Constraints

• Rollback

Which map cleanly onto cohesive business operations.

This does not make them universally superior.

It makes them unsurprising.

When your model is simple, simple tools fit.

When your model is fragmented, no tool will feel simple.

ACID as a Complexity Indicator

This perspective does not attempt to accommodate every architectural fashion.

It does not try to explain how ACID can be stretched, simulated, or approximated in increasingly fragmented systems.

Instead, it treats ACID as a simple indicator:

When a business operation can no longer be expressed as a straightforward success-or-failure unit, the system has already become more complex than it needs to be.

That complexity may be intentional.
It may be justified by extreme scaling constraints or unusual operational environments.

But it is still complexity.

ACID is useful precisely because it makes this visible.

Not as a rule to obey.
Not as a feature to retrofit.

But as a signal:

If drawing a cheap ACID boundary feels unnatural, forced, or impossible, that is not a limitation of ACID.

It is a sign that the application’s structure has drifted away from the simplest expression of its business intent.

ACID as a Mirror

ACID does not impose discipline.

It reflects discipline.

When ACID feels heavy, awkward, or impossible, that is a signal worth listening to.

Not about databases.

Not about frameworks.

But about whether the essential complexity of the domain is still visible, coherent, and whole.

In that sense, ACID is less a technology choice than a mirror.

And mirrors are useful precisely because they do not lie.

The outcome is correct.
The task is completed.

Yet the Ferrari is:

• Excessively expensive for the job

• Fragile under the wrong conditions

• Costly to maintain

• Poorly suited for rain, mud, or sustained use

In the real world, everyone knows a Ferrari is not the right tool for plowing. We have tractors. We have benchmarks. We understand what works and why.

Now imagine the only field in the world. There are no other machines to compare it to. No tractors, no benchmarks, no historical experience — just the Ferrari. It works. The field is plowed. But we have no way to judge its suitability, efficiency, or long-term cost.

This is the world of software engineering. Every company building custom applications faces this reality: there is no reference frame, no control group, no benchmark beyond whether the system “works.” Success becomes the only visible measure, and quality in any deeper sense is unknowable.

What does this mean for how we design, implement, and maintain software? That’s what the singleton reality is all about.

The Singleton Reality

There is no true A/B testing in software architecture.

You cannot take the same system and implement it twice — once with Framework X, once with Framework Y.
You cannot run the same organization through CQRS and a layered monolith under identical conditions.
You cannot replay the same business evolution using synchronous calls instead of event-driven architecture.

Once a system is built, it proceeds along a single, irreversible path.
Architecture, framework, and tooling collapse into one history.

And like the Ferrari plowing a field, the system produces results.

Features ship.
Users are served.
The business functions.

But without knowledge of the tractor — without a grounded understanding of what a fit-for-purpose architecture looks like for this kind of problem — there is no way to judge:

• Whether the design is economically rational

• How much accidental complexity was introduced

• What long-term maintenance will cost

• Or whether a simpler, more robust approach would have been better

The system works — and that success silences the question of suitability.

Success Silences Better Questions

In singleton systems, success suppresses counterfactuals.

If the system works:

• The tools get credit

• The architecture is justified retroactively

• The design choices are treated as “proven”

Inefficiencies are explained away as:

• “The domain was hard”

• “The requirements were unclear”

• “The team didn’t execute well enough”

Rarely do we ask whether the approach itself was ill-suited.

This creates a dangerous asymmetry:

If the system doesn’t work, it invites analysis.
If the system works, analysis is unnecessary.

So the system is never evaluated for appropriateness, economy, or durability.

Working Software Is Not the Same as Good Engineering

In software, we conflate correct output with engineering quality.

But “it works” tells us nothing about:

• How difficult the system is to change

• How much knowledge it takes to maintain

• Whether complexity reflects the domain or the tooling

• Whether the system can survive years of learning and correction

A Ferrari plowing a field will:

• Break more often

• Cost more to maintain

• Fail catastrophically under the wrong conditions

None of this is visible if the only metric is “the field got plowed.”

This is the core problem of singleton systems:

They hide misfit behind functionality.

The Drift From Engineering to Assembly

Because systems are singletons, pressure accumulates in one direction:

• Deliver features

• Meet deadlines

• Make it work

The dominant question becomes:

“Does this solve today’s problem?”

Not:

“Is this the right kind of solution for the kind of problem this is?”

This is where engineering quietly gives way to assembly.

As long as behavior is correct, no one examines:

• Whether internal structure is legible

• Whether essential complexity is visible

• Whether tomorrow’s changes have somewhere to go

The Ferrari plows the field.
The conversation ends.

When “It Works” Becomes the Only Optimization Target

Once success is defined purely by outcome, optimization silently shifts.

If the only question is:

“Does it work?”

Then the system is no longer optimized to be understood or changed.

It is optimized for least resistance to implementation.

This shift is not incompetence.
It is a rational response to pressure in a system where correctness is the only visible metric.

Implementation Is the Easy Part

Writing code that produces the correct result is rarely the hard problem.

Modern languages, frameworks, and tooling are extremely good at helping us implement behavior.

The difficult work is something else entirely:

• Understanding the domain

• Discovering which rules actually matter

• Learning which constraints are essential and which are incidental

• Knowing where behavior truly belongs

That understanding emerges slowly — through use, failure, and correction.

But when optimization is focused solely on “making it work,” that understanding is treated as overhead.

Optimizing for Least Resistance

When resistance to implementation becomes the primary concern, certain patterns appear everywhere:

• Behavior collapses into declarative annotations

• Constructors are reduced to wiring points

• Objects lose responsibility and become data carriers

• Framework conventions replace explicit structure

Each of these choices reduces friction today.

They allow engineers to focus almost exclusively on tooling — the mechanically easy part of software construction.

And each of them quietly removes something far more valuable.

They erase information about why the system behaves the way it does.

What Gets Lost Is Not Functionality — It Is Meaning

The system continues to function.

Features ship.
Tests pass.
Users are served.

But the code stops explaining itself.

It no longer communicates:

• Why a rule exists

• Why a boundary matters

• Why a concept deserves to be modeled explicitly

That knowledge migrates into:

• The heads of a few people

• Tribal conventions

• Framework internals

• Historical accidents

The Ferrari still plows the field.

Why This Undermines Endurance

Software endures not because it was easy to write, but because it remains possible to re-understand.

Long-lived systems must absorb new knowledge:

• New edge cases

• New constraints

• New interpretations of old rules

If the code was optimized only for minimal resistance during implementation, it offers no structure to integrate that learning.

Change becomes additive instead of corrective.
Patches accumulate.
Workarounds replace design.

The system still works — but it can no longer evolve cleanly.

Essential vs. Accidental Complexity

Every system contains essential complexity — the irreducible complexity of the domain itself.

Good engineering keeps that complexity:

• Explicit

• Legible

• Close to the code

Bad engineering replaces it with accidental complexity:

• Framework indirection

• Implicit behavior

• Generated wiring

• Convention-heavy design

In a singleton system, accidental complexity is especially dangerous.

Because there is no steering mechanism.

If essential complexity is no longer legible, the system can evolve only by:

• Upgrading dependencies

• Adding patches

• Introducing workarounds

When essential complexity is no longer visible, corrections are no longer possible — only compensations. Workarounds emerge in place of design.

Code Changes Because Understanding Changes

Software does not change primarily because developers make mistakes.

It changes because understanding grows.

Teams learn:

• Which rules actually matter

• Which edge cases are fundamental

• Where earlier assumptions were wrong

If the system was written only for today’s understanding, that new knowledge has nowhere to live.

It gets bolted on.
Hidden behind flags.
Embedded in conditionals.

The system still works — but its internal coherence degrades.

Expressive systems behave differently.

They give new understanding a place to land.

Expressiveness as a Survival Strategy

Expressive code does not exist to be verbose.

It exists to:

• Name concepts explicitly

• Encode invariants visibly

• Make responsibility undeniable

• Preserve the shape of the domain over time

In a world of repeatable systems, this might be optional.

In a world of unique singleton applications, it is essential.

Because expressiveness preserves engineering intent when outcomes alone cannot tell us whether we chose the right machine.

Tooling Is Not Architecture

One of the clearest signs of singleton failure is when:

• Removing a framework collapses the system

• Upgrading a dependency requires redesign

• Behavior lives in annotations instead of code

• The runtime behaves in ways the source does not explain

This is not leverage.

It is hidden coupling.

The system works — until it doesn’t.
And when it breaks, understanding is nowhere to be found.

Conclusion: Engineering Without Second Chances

The singleton reality does not make quality impossible.

It means quality is never proven by success alone.

A working system may still be:

• Overengineered

• Underfit

• Fragile

• Economically irrational

Just like a Ferrari plowing a field.

Good software engineering, under singleton conditions, is not about modernity or brevity.

It is about preserving:

• Legible essential complexity

• Explicit assumptions

• Structural honesty

Because in a world where every system is built once,
the only thing that survives is what continues to explain itself.

And if we never ask whether we’re building tractors —
we will keep celebrating Ferraris that merely happen to work.

They are described as entangled, brittle, slow to change, and resistant to scaling. These observations are often factually correct. Integrated systems do create friction.

But friction is not always a defect. In many systems, friction is a signal.

This article argues that much of what was labeled “entanglement” in integrated systems was actually an early-warning mechanism. When that mechanism was removed through distribution, the underlying problems did not disappear. They became quieter, slower, and significantly more expensive.

The failure moved from code into data.

The Alarm That Integrated Systems Produce

In physical systems, noise is rarely neutral. A rattling engine or grinding gearbox indicates misalignment. The noise is not the problem; it is evidence of one.

Integrated software systems behave similarly.

When business logic is tightly integrated, several forms of friction emerge:

• Changes in one area break assumptions elsewhere

• Builds fail when invariants no longer align

• Tests surface unexpected dependencies

• Transactions roll back when rules conflict

This friction is commonly interpreted as a sign that the system is “too coupled” or “badly designed.” The usual response is structural separation: splitting the codebase into independently deployable units.

The immediate effect is predictable. The noise stops.

What is often overlooked is that the absence of noise does not imply the absence of misalignment. It only implies that misalignment is no longer detected early.

Integrated Code and Fail-Fast Reality

An integrated codebase has one defining property: assumptions are forced to reconcile early.

When domain logic is integrated:

• There is a shared model of state

• Business rules are enforced atomically

• Invariants are validated before data is committed

If a rule changes, dependent logic is affected immediately.
If a concept becomes inconsistent, the compiler or transaction boundary rejects it.
If two parts of the system disagree, progress stops.

This is not a matter of code quality or architectural purity. It is a structural consequence of integration.

Integrated systems fail fast not because they are fragile, but because they refuse to accept inconsistency. The system either makes sense, or it does not proceed.

This early resistance is often experienced as development pain. In reality, it is risk surfacing at the lowest possible cost.

The Myth of the Clean Split

Distributed architectures are frequently justified by the promise of independence: teams can move faster, deploy separately, and avoid stepping on each other’s work.

What is actually being split, however, is not just code.

What is split is the contract of truth.

In an integrated system:

• Integration happens in code

• Assumptions collide during development

• Failure is immediate and visible

In a distributed system:

• Integration moves to runtime

• Assumptions no longer collide synchronously

• Failure becomes delayed and ambiguous

This creates a structural visibility gap:

When integration leaves code, it does not disappear.
It reappears in production data.

Why Distribution Feels Easier

Distributed systems often feel easier to work with, especially at scale. This perception is not accidental. Distribution optimizes for a different kind of effectiveness.

Modern distributed architectures reward:

• Framework proficiency

• Infrastructure and deployment literacy

• API boundary design

• Local correctness within a bounded context

• Tooling fluency (CI/CD, observability, orchestration)

These skills are valuable and necessary. But they share a defining characteristic: they allow productivity without global understanding.

An engineer can be effective inside a service without understanding how the broader domain behaves as a whole.

Integrated systems do not permit this mode of work.

To make meaningful changes in an integrated codebase, it is necessary to:

• Understand upstream and downstream effects

• Reason about invariants across modules

• Grasp end-to-end data flow

• Understand why rules exist, not just where they are implemented

This is not a question of intelligence or seniority. It is a question of cognitive scope.

Integrated systems enforce holistic reasoning.
Distributed systems allow local reasoning.

Skill Distribution and the Integration Tax

This difference in cognitive scope has architectural consequences.

Distributed systems scale teams more easily than they scale coherence. They lower the barrier to entry by allowing work to be partitioned into technically isolated units. This is often a deliberate organizational choice.

However, the cost is subtle and delayed.

When engineers are incentivized to reason locally:

• Decisions are optimized for individual services

• Tooling validates only local correctness

• Tests confirm behavior in isolation

• Deployment pipelines signal success prematurely

Nothing in the system enforces semantic alignment across services.

Data misalignment is therefore not caused by poor engineering. It is caused by locally correct decisions made without global constraint.

Integrated systems make this kind of drift difficult. Distributed systems make it likely.

This increased probability of misalignment is part of the integration tax.

Data Duplication and Semantic Drift

To function independently, distributed systems duplicate data.

Each service maintains:

• Its own schema

• Its own representation of shared concepts

• Its own interpretation of business state

Initially, everything works. APIs respond. Events flow. Tests pass.

Over time, meanings diverge.

One service treats “Cancelled” as refunded.
Another treats it as pending return.
A third treats it as archived and immutable.

Each interpretation is internally consistent. None are aligned.

APIs do not renegotiate meaning when assumptions change elsewhere. They preserve contracts long after those contracts no longer reflect reality.

This divergence is known as semantic drift.

It is invisible during development, invisible during deployment, and invisible to monitoring systems.

Data Decay: Failure Without Alarms

Semantic drift leads to a more dangerous failure mode: data decay.

Data decay is the gradual corruption of business truth caused by delayed semantic misalignment in distributed systems.

Its defining traits are:

• No crashes

• No failed builds

• No immediate customer-facing errors

• No alerts

Instead, it surfaces indirectly:

• Financial reports fail to reconcile

• Regulatory numbers drift

• Manual correction jobs become permanent

• “Temporary” analytics fixes accumulate

By the time the problem is detected, the system has often been producing incorrect data for months.

The failure did not happen at the moment of discovery. It happened when assumptions silently diverged.

Continuous Deployment as an Accelerator

Continuous Deployment is often presented as a safety mechanism: smaller changes, deployed more frequently, reduce risk.

What actually changes is where integration happens.

In distributed systems, continuous deployment accelerates the rate at which assumptions enter production. Integration no longer happens before release; it happens in live data.

Conflicts are not rejected. They are accumulated.

The system appears stable because nothing crashes. But stability is not correctness.

Deployment speed increases, while semantic alignment lags behind.

Integrated Truth and Transactional Boundaries

This is not an argument against distribution in all forms. It is an argument against distribution without an integrated core of truth.

Somewhere in the system, there must be:

• A place where invariants are enforced

• A boundary where business rules meet

• A transaction where assumptions are forced to align

When such a boundary exists:

• Changes propagate before data is committed

• Misalignment fails early

• Truth remains atomic

When it does not, coherence must be enforced organizationally rather than architecturally. That is a far more expensive mechanism.

The Real Integration Tax

The integration tax is rarely paid in performance or build times.

It is paid in:

• Growing headcount to manage inconsistencies

• Reconciliation teams and data cleanup pipelines

• Manual exception handling

• Loss of trust in reporting

• Regulatory exposure

• Permanent compensating processes

Integrated systems force discipline early.
Distributed systems defer discipline until it becomes unavoidable.

Conclusion: The Singleton Trap

If integration is difficult in code, the design requires work.
If integration is difficult in data, the organization is already paying for failure.

The industry-wide shift toward distributed systems was an attempt to bypass the friction of integrated codebases. That friction, however, was not eliminated; it was displaced. The result is a quieter, more pervasive crisis.

Every instance of data decay is effectively a singleton: a unique outcome of a specific architectural sprawl combined with a particular set of organizational boundaries. Because no two failures look the same, there is no shared baseline for comparison and no obvious signal that something systemic is wrong.

In the absence of a universal yardstick, the consequences are normalized. Expanding headcount, permanent reconciliation teams, and continuous data-cleaning pipelines are often treated as the natural cost of software at scale.

They are not.

They are the measurable price of silencing an architectural alarm.

Integrated systems make misalignment audible while the cost of correction is still low. Distributed systems render it silent, allowing it to accumulate until it manifests as institutionalized overhead. Silence is not safety; it is deferred truth.

The interest on that debt is paid in the long-term integrity of the business.

The culprit is not technical debt in the abstract, nor insufficient process maturity. It is cognitive load—the amount of mental effort required for developers to understand, reason about, and safely change a system.

High cognitive load does not appear on balance sheets. It does not trigger alerts or dashboards. But it quietly drains delivery speed, inflates costs, and erodes morale. Over time, it becomes a direct and measurable profit killer.

What Is Cognitive Load (in Software)?

In software development, cognitive load is the mental overhead required to answer seemingly simple questions:

• What is this code trying to do?

• Why does it exist?

• What business problem does it solve?

• What will break if I change it?

When these answers are obvious, change is cheap. Developers can act with confidence, make localized modifications, and move on.

When the answers are hidden behind layers of indirection, speculative abstractions, and unclear responsibility, every change becomes slow and risky. Developers must reconstruct intent before they can touch behavior.

Crucially, cognitive load compounds. Each unnecessary abstraction, ambiguous name, or misplaced responsibility increases the effort required for the next person. Over time, the system becomes harder not because it does more, but because it explains less.

The “Busy” Paradox

Consider a familiar situation.

You have a team of ten senior developers. Everyone works full-time. Standups are attended. Tickets move across the board. And yet, after two weeks, the sprint produces a single minor feature.

Where is the time going?

It is not laziness.
It is not incompetence.
It is cognitive friction.

Most of the team’s energy is spent rebuilding mental models: reloading context, rediscovering intent, and validating assumptions that the code itself should have made explicit. Progress is slow not because developers are typing less, but because they are thinking harder than necessary.

Organizations are not blind to this problem. A common response is standardization. Codebases are aligned around familiar structures: services contain logic, repositories handle persistence, controllers orchestrate flows. Frameworks are standardized so that “everything looks the same.”

This helps with orientation, but not with understanding.

The problem is rarely the technology or the mechanics of execution—the how. The real cost lies in the why and the what: why this behavior exists, what business rule it enforces, what outcome it protects.

That information is often missing from the code itself. Instead, it is learned slowly through debugging sessions, tribal knowledge, and historical accidents. Weeks or months pass before a developer truly understands what the system is doing and why. This is where the real time and money are lost.

1. The Backlog Tax: Why Deferring Fixes Is Financial Suicide

Most organizations treat their backlog as a neutral to-do list. In practice, it behaves like a high-interest credit card.

The Logic

A developer is implementing a feature and notices a small bug, an awkward name, or a local design flaw. At that moment, the relevant mental context is fully loaded:

• They understand why the code exists

• They know which constraints matter

• They can judge the safety of a change immediately

This is the cheapest possible moment to improve the system.

The Waste

Instead, the issue is logged in Jira.

Two months later, another developer picks it up. Before making a five-minute fix, they spend hours:

• Reconstructing domain knowledge

• Tracing execution paths

• Rebuilding trust in unfamiliar code

The cost was not deferred—it was multiplied.

This problem compounds further because these issues are rarely urgent. They are perpetually deprioritized in favor of “more important work.” The backlog grows, the friction increases, and the same irritations are encountered sprint after sprint, each time with the silent promise: “We’ll fix this next time.”

The result is a system that is increasingly expensive to work on, not because it is complex, but because its intent has decayed.

The Rule

If you see it, and you are already there, fix it now.

Deferring known improvements is not prudence. It is a deliberate increase in future cognitive load.

2. The Alignment Gap: Why “How” Is Expensive Without “Why”

Few things increase cognitive load faster than unclear intent.

The Logic

When developers do not fully understand the business goal, they compensate by writing defensive code:

• Over-general abstractions

• Configuration points for hypothetical futures

• “Just in case” extension mechanisms

This is not foresight. It is fear.

The code attempts to remain flexible because the developer cannot be confident about what actually matters. The result is speculative complexity—structures designed to support scenarios that never occur, but must still be understood and maintained.

The Cost

Speculative complexity bloats the codebase and obscures meaning. Every reader must mentally filter out irrelevant paths and imagined use cases to locate the real behavior.

When the why is clear, the code can be written with purpose. It describes business intent rather than technical possibility. Behavior becomes traceable to outcomes, and understanding becomes dramatically easier.

The Rule

Clarity on the “Why” dramatically simplifies the “How.”

In practice, complete clarity on intent often results in far less code—and far less cognitive load—because the system only expresses what is necessary.

3. Mechanics vs. Meaning: Where Design Becomes a Cognitive Problem

At this point, cognitive load stops being a process issue and becomes a design issue.

The Mechanic: Procedural Thinking in Disguise

In many modern systems—often Spring-based—business logic is implemented procedurally:

• Service layers orchestrate behavior

• DTOs move state between components

• Methods mutate data from the outside

To understand what is happening, the reader must behave like a debugger: jumping between files, tracking values, and inferring intent from side effects.

The code explains how things happen, but not why.

The Meaning: Domain-First Design

In a domain-first design, meaning is explicit and behavior lives where it belongs.

Compare:

orderService.updateStatus(orderId, Status.CANCELLED, currentUser);

with:

order.cancel(currentUser);

The second version immediately reduces cognitive load:

• The intent is explicit

• Responsibility is unambiguous

• Invariants are enforced at the right level

The reader no longer needs to infer meaning from mechanics. The code communicates its purpose directly.

The Knowledge Leak: When Intent Lives Outside the Code

If your code only encodes how to perform a task, but not why it is doing it, you are losing money every time a developer presses “Save.”

When business intent is not embedded in the domain model, it leaks out of the codebase and into external systems: Jira tickets, Slack threads, pull request comments, and long-forgotten emails. The system may still work, but its meaning no longer lives where developers need it most.

Every future change now requires archaeology.

Developers must dig through history to reconstruct intent:

• Why was this implemented this way?

• What constraint was it protecting?

• Is this behavior accidental or deliberate?

This makes teams brittle. Bugs become expensive because intent must be rediscovered before it can be corrected. Developers become non-interchangeable because knowledge accumulates in people rather than in code. Staff turnover turns into operational risk.

The Cost of Manual Abstraction

Procedural code forces developers to perform manual abstraction every time they revisit it.

They must translate mechanical steps—loops, flags, state mutations—back into business meaning in their own heads. This translation is repeated by every developer, every time, slightly differently. It is pure waste.

A Rich Domain Model performs that abstraction once.

By encoding the why directly into the code, the system communicates its purpose at a glance. Intent is no longer inferred; it is declared. From that point on, understanding is cheap, bugs are easier to identify, and developers become far more interchangeable.

Lower cognitive load does not just improve readability.
It makes the system resilient—to team changes, shifting priorities, and market pressure.

The Rule

Contextualize everything.

If the code does not explain its own business meaning, it is technical debt—regardless of how clean, testable, or well-structured it appears.

A Useful Analogy: Action Without Context

Procedural or purely functional code often resembles a script containing only actions:

• Do this

• Then that

• Then something else

It is like reading a comic book with only motion lines and no panels explaining who is acting or why.

Contextualized code provides both action and context. That context dramatically reduces the effort required to understand, change, and trust the system.

The Financial Audit: Calculating the Profit Killer

Cognitive load is a recurring line item on your balance sheet. To understand the true cost, compare two organizations:

The Real-World ROI

If you have a team of 10 developers and you reduce their cognitive load by just 25%, you aren't just making them happier. You are effectively gaining 2.5 full-time senior engineers without increasing your payroll by a single cent.

Conversely, every hour your team spends deciphering "mechanical" code or grooming a stale backlog is an hour of capital investment that yields zero business value.

Final Thought

The most profitable optimization you can make is not faster infrastructure or better tooling. It is the ruthless pursuit of software that is simply easier to think about. Reducing cognitive load lowers the barrier to entry for new talent, reduces the risk of knowledge silos, and—most importantly—returns your team to a state of high-velocity delivery. If your codebase has become a puzzle that only your most senior developers can solve, you are dealing with a bottleneck that is actively harming your bottom line.

Abstract CVE-2026-0603, disclosed on January 19, 2026, describes a high-severity (CVSS 8.3) second-order SQL injection vulnerability in Hibernate ORM’s InlineIdsOrClauseBuilder. The issue arises when unsanitized string values are incorporated into dynamic IN or OR clauses during query construction. This article examines the vulnerability’s mechanics, affected versions, and conditions under which applications remain unaffected, with particular emphasis on systems that employ sequence-generated numeric primary keys.

Introduction SQL injection vulnerabilities remain a persistent threat in object-relational mapping (ORM) frameworks. CVE-2026-0603 affects Hibernate ORM when string-based identifiers are processed in a manner that permits injection of malicious SQL fragments. The vulnerability is classified as second-order: malicious input must first be stored in the database and later retrieved for use in a dynamic query.

Vulnerability Description The flaw resides in the construction of SQL clauses that combine multiple identifier values. When identifiers are strings, Hibernate may concatenate values without sufficient sanitization, enabling an authenticated attacker with low privileges to store SQL metacharacters (e.g., quotes, comments, semicolons) in a field that later serves as an identifier. Subsequent query execution can result in arbitrary SQL statements, leading to data exposure (high confidentiality impact), unauthorized modification (high integrity impact), or limited denial-of-service (low availability impact).

Affected Versions The vulnerability impacts Hibernate ORM versions 5.2.8 through 5.6.15. Red Hat products incorporating vulnerable Hibernate builds (e.g., JBoss EAP, Fuse, OpenShift Application Runtimes) are also exposed.

Conditions for Non-Exposure Applications are not vulnerable when primary keys are exclusively numeric (Long/BIGINT) and generated by database sequences. In such cases:

• Identifier values are controlled by the database and never originate from user input.

• Hibernate processes numeric identifiers as bind parameters or literal numbers, bypassing string concatenation logic.

• The vulnerable InlineIdsOrClauseBuilder path is not executed.

This configuration effectively prevents exploitation, even on unpatched versions.

Discussion The use of user-supplied values as primary keys or identifiers introduces unnecessary risk. Numeric, sequence-generated keys provide a robust defense-in-depth layer against injection and enumeration attacks. When user-controlled values (e.g., usernames, slugs, codes) are required, they should be stored in separate indexed columns with strict validation, normalization, and sanitization. Direct use of such values as identifiers violates separation of concerns and increases attack surface.

Conclusion For applications that rely solely on sequence-generated numeric primary keys, CVE-2026-0603 presents no practical risk. Patching remains advisable for general hygiene, but urgency is low in these environments. Systems employing string-based identifiers, particularly those influenced by user input, require prompt remediation.

References

• Red Hat Security Advisory: https://access.redhat.com/security/cve/cve-2026-0603

• Related discussion on dependency update practices: https://blog.leonpennings.com/why-blind-dependency-updates-are-costing-java-teams-more-than-they-save

Correction (Feb 2026): Affected versions are Hibernate ORM 5.2.8 through 5.6.15 (per Red Hat advisory). Earlier reports listed 6.x in error — 6.x is not impacted. Core advice unchanged.