Frequently I see the same question in many forms; "How do I design a web application architecture". The simple answer is that all application architectures are different, depending on the actual needs. Instinctively most programmers know what's required, or at least we think that we do.
bq. The true skill is to realise that we are often wrong and that any architecture design needs to be validated.
h2. Pragmatic approach to application architecture
Pragmatism is one of those often misapplied terms that is often used interchangeable with "in my experience". If you trace back the origins of pragmatism to its philosophical base in the wisdom of William James he defined pragmatism as "the truth of an idea needing to be tested to prove its validity". This exactly equates to the way that we should build anything complex, by using the practical over the theoretical.
There are all too often basic premises upon which systems are designed that are simply wrong and all too often these premises can overlap with a previous approach or even fall foul of the dreaded second system effect.
bq. Theoretical approaches can work well. New theories need to be tested and it is by doing so that we can translate theory into practice.
h2. Web Application Architecure Diagram
The following is the result of a design that took around 6 months of testing and tweaking. It is a second generation partial redesign of a real live web application architecture that is in production, or was last time I checked.
h2. Web Application Architecture requirements analysis.
Step 1 of any design process is to analyse the requirements and produce a set of goals that the architecture must fulfil. Sometimes, and unfortunately, technology is mandated for business or operational requirements so these have to be included. Rarely by proving that technology is simply unsuitable it is possible to replace it with something better. Avoid the trap of thinking something is better simply because it is familiar. When working in a team try to avoid comfort zones. I once worked with someone who was an absolute wizard with Finite State Engines and could produce miraculous results. The only snag was that the problem was often moulded to the solution, when in fact something other than a FSE would be a better (and more maintainable solution).
bq. Analyse and write down your requirements. If reliability isn't the primary goal then rewrite your requirements until it is. If maintenance and extensibility aren't in the top five then review again.
h2. Web Application Architecture requirements analysis.
Step 1 of any design process is to analyse the requirements and produce a set of goals that the architecture must fulfil. Sometimes, and unfortunately, technology is mandated for business or operational requirements so these have to be included. Rarely by proving that technology is simply unsuitable it is possible to replace it with something better. Avoid the trap of thinking something is better simply because it is familiar. When working in a team try to avoid comfort zones. I once worked with someone who was an absolute wizard with Finite State Engines and could produce miraculous results. The only snag was that the problem was often moulded to the solution, when in fact something other than a FSE would be a better (and more maintainable solution).
bq. Analyse and write down your requirements. If reliability isn't the primary goal then rewrite your requirements until it is. If maintenance and extensibility aren't in the top five then review again.