Every Developer Is Already an Architect

Most developers think architecture is someone else’s job.

It’s what the architects do.

Or the tech leads.

Or the people who spend their days drawing boxes and arrows.

It’s not on your job description, so it’s not your problem.

Except it is.

By the time you’ve been building software for a few years, you’re already making architectural decisions.

You just don’t call them that.

A year later it's called "The Architecture"

You’re implementing a new feature. An order has to notify the warehouse once it’s paid.

You need to decide where that notification comes from.

Do you call the warehouse API straight from the payment handler, because it’s two lines and the ticket is due Thursday?

Do you publish an event instead, and let the warehouse subscribe to it?

Do you put the rule — an order notifies the warehouse once it’s paid — inside Order, or in whichever service happens to be holding it?

Do you reuse the HTTP client that’s already wired up in the payment module, or give the warehouse call its own?

None of these decisions feel like “architecture.”

They seem to be just implementation details.

Until a year later.

A year later, a new developer joins and asks why payment knows about the warehouse. Why the notification rule lives in a service instead of in the order. Why there are four HTTP clients configured against the same host.

Nobody has an answer. The person who made those calls has moved on, or doesn’t remember, or never thought about it much...

But the answers have hardened. The direct call became the pattern everyone copied. The rule in the service became the reason Order can’t be tested without a database. The four clients became the reason a timeout change takes a day.

That’s what the team now calls “the architecture.”

Nobody designed it. It accumulated.

The line between developer and architect isn't a promotion

Architecture isn’t something you do before writing code.

It’s something you do every time you write code.

So the difference between a developer and an architect isn’t the title, and it isn’t permission from someone above you. It’s whether the decision got made on purpose.

Sometimes the direct call really is the right answer.

Picture two developers who both write it. The first one weighed it: the warehouse call is rare, a failed notification is recoverable, an event bus would cost more than it saves right now. The second one wrote it because it was the shortest path on a Thursday.

Read the code today and you can’t tell them apart. It’s the same two lines.

The difference shows up the day the assumption breaks — when the call stops being rare, or a lost notification starts costing real money.

The first developer knows exactly what they traded away, so they recognize the moment the trade stops paying.

The second left nothing behind to revisit, so nobody notices. The line just gets copied into the next three features, because by then it looks like a decision somebody made.

Next time you reach for the shortest path, ask the architect’s question: what does this make cheap later, and what does it make expensive?

You’re already making the decision.

Make it deliberately.

⚡Clean Architecture in practice

Which class should own a business rule?
What’s allowed to depend on what?
Which calls to the outside world you should be able to swap for a fake when you test?

Nobody tells you that along with the title.

Join the live training session:

🗓 Clean Architecture for Backend Developers (Wed Aug 26)