It’s easy to think of an application as having “an architecture.” We talk this way a lot, in software development. But the more I build similarly-architected systems and new systems with different architectures, the more I realize that architecture is not a single thing. Rather, architecture is a fluid and living thing – it grows, it shrinks, it changes over time.
An application’s architecture is not a single thing, but a collection of things that form the living whole.
A Single Application’s Architecture
I’m building a Backbone.js application for my client these days. It’s a component-based application architecture. There are many individual parts of the screen that are broken down into controllers using the mediator pattern, with views that show things.
But it’s also a messaging based architecture where I am using pub/sub (event aggregator), request/response and commands through an in-memory message broker. This is one of the ways that unrelated components communicate with each other.
It also contains a wizard-style workflow where I register steps and views for each steps. There is an architecture in and of itself in this – beyond the mediators, and beyond the broker – to facilitate the flow between high level steps.
Then, there’s the back-end code on the server – a middleware based stack of request handlers. Various HTTP handlers get called at various times, for authentication, authorization, APIs and other aspects of the web server.
Oh, and there’s a messaging architecture on the back-end as well, with it’s own broker. And each of the applications sitting on the other side of the queue has it’s own architecture, still.
But wait, there’s also …
Let It Grow. Let It Find It’s Own Shape.
My Backbone application did not start out with this architecture in mind. Sure, I had an idea that I wanted to do component-based UI with Backbone. I set out to implement that because of the complex UI needs. But along the way, I found the need for the wizard. I found the need for unrelated components to communicate with each other. I found the need to coordinate multiple view implementations with a single, higher level workflow … and so much more.
I found the need for most of this architecture, rather than forcing the application in to a given architecture. I also know that the architecture that I have next month will not look entirely like what I have today. I will let the application grow and let the features and functionality determine the new and ever-changing shape of the architecture as I build.
I encourage you to do the same. Don’t force an application’s feature set in to “the way things are”. Question the current design and look for opportunities to change, improve and grow the application in a meaningful way.