While architecting software systems all we have to do is what will change and what will be static. What can be enhanced and what can be removed. I find this principle at the core of Design Patterns.
Whatever can change (and this question needs to be answered on regular basis) one needs to put it on a process space. If these processes are well defined then you can scale them, maintain them, enhance them independently. Each component exposes some functionality what we can call “Service”. Most of the time developers these days relate Service with S in SOA and when it is done they immediately assume it is a “Web Service”. This is wrong understanding from my point of view.
Any piece of software that exposes some functionality can be termed as a Service. It is a generic term and Web Service is just one way of creating and consuming services. More about this in later articles.
Once we answer above questions (which will require deep domain thinking) we can just start developing small systems (Divide and conquer eh h?) and wire them together. Once this wiring infrastructure is already in place a new developer can create a new module when a new functionality is needed and you can be at peace that even if he messes up you can just stop his system.
Easier said then done. Software Architecture had to be developed scientifically and bigger picture needs to be kept in mind. Though there can be thousands of factors which go in determining how architecture for application should be designed but in this blog we will focus on how things can be simplified.
Before we start looking at these principles we need to accept that today lot of design decisions are being influenced by what Twitter/Facebook/LinkedIn are doing.
This is not wrong but it influences our approach. These websites are not built in a day and it takes years to reach that stage. When that time comes you will automatically know what to do.
For now we focus on systematic approach.
Key guidelines
- Separation of concerns
- Single Responsibility principle.
- Don’t repeat yourself (DRY)
There can be many more but these 3 rules in my opinion are the guiding light for a maintainable application.
1 & 2 are complimentary. 3rd principle is made more popular by frameworks like ROR but concept is simple “do not write same kind of code again and again”.
Use shared library, create a web service, deploy in different container instance etc. etc.
We have to remember that discipline is the most important key factor in engineering and software development is know different.
If we follow basics there is very little room for error we can leave. In case of any confusion we fall back to basics again. In practice you will find many people preaching about this but very few following these principles as it comes by practice.
1 & 2 are self descriptive for a seasoned programmer. You try to think as small as possible and expose that functionality. e.g. In an E-commerce site Payment Gateway module has got nothing to do with OrderProcessing module. Though there can be dependency but their logic is totally independent.
So there is a strong reason for separating them out.
If we think small there can be many instances when we can make small modules. Don’t be afraid how modules will work together for now. We will talk about that later.
A geek's blog 