From Shared Code to Shared Architecture

By this point I knew what the problem was.

Every new application meant another copy of the same infrastructure. Every improvement meant updating multiple projects. The duplication wasn't making development difficult—it was making maintenance expensive.

My first instinct wasn't to build a framework.

It was simply to stop copying code.

The obvious place to start was with the parts that almost never differed between applications.

The website header.

The footer.

The navigation.

Instead of maintaining separate copies, I began sharing them between applications. Suddenly a change to the site's appearance only needed to be made once.

That small change had a surprisingly large effect.

The more code I shared, the more I realised that the same principle applied elsewhere.

Configuration files didn't need to exist in every project.

Common helper functions didn't need to be duplicated.

Authentication didn't need to be rewritten.

Database access could be standardised.

Even the overall page layout could become a reusable component rather than something recreated for every application.

None of these changes happened overnight.

They emerged gradually, usually because I'd become tired of maintaining multiple versions of the same solution.

Each time I removed another piece of duplication, the applications became easier to maintain and more consistent with one another.

Eventually I realised that something interesting had happened.

I wasn't just sharing files any more.

I was sharing behaviour.

Applications were beginning to rely on a common set of services rather than implementing everything themselves. Instead of every project deciding how to initialise itself, they all followed the same process.

Without consciously planning it, I'd started defining an architecture.

That was an important turning point.

The goal was no longer to reduce duplicated code. The goal was to provide a consistent way for every application to work.

Once every application followed the same conventions, adding a new one became much simpler. Instead of copying an existing project and modifying it, I could start with a small amount of application-specific code and allow the shared platform to provide everything else.

Looking back, I don't think frameworks are usually created by sitting down and deciding to invent one.

They evolve because repeated solutions eventually become common services.

When enough of those services come together, you've built a framework—whether you intended to or not.

For me, the Auspice Darer Framework wasn't a destination I set out to reach.

It was simply the natural consequence of removing duplication until only the application itself remained unique.