Sunday, March 15, 2009
Coupling & Architecture:
We all have read about tight and loose coupling. We all are aware that there exists two major type of couplings but, how many times did we try to depict and use the concept of loose coupling in our architecture? I am sure we are more driven towards tight coupling atleast practically. The reasons are:
1. Tight coupling is obvious option when scope of software application is small.
2. When development is required at rapid pace.
3. When debugging needs to be made easy for atleast new team members.
But, when this small application tries to add features and when complexity increases, we are often struck with evil called tight coupling. The reason?
The reason is straight forward. Each change in one component calls for changes in almost all other components, due to inter-dependency factor, known to us as tight coupling. It is because, each of our interacting components known more that what it needs, about the other component and hence, maintains some form of data or functionality dependency about the other component, with which it is interacting. This dependency obstructs our maintenance and feature building within our present architecture. And the intensity of evil increases when we add more new developers to the team. All new developers added, are hardly aware of already present complexity and their main aim is to some how manage, and get the feature working. This further accelerates the already complex situation.
When such situation arises, we are often seen compromising with many critical factors like: a) Optimization b) Resource utilization etc etc.
Then what is the way out?
The only way out is, while architecting a system always try to design a loosely coupled system. I agree, often during the initial phases, it will feel like a burden, from both architect and developers perspective. But, as an architect our aim is to NOT only think of present, but also of future. In most of the cases, we see that all system/application grows with time and hence desiging a loosly coupled system will always pay in long term.
But what exactly is loosely coupled design?
A loosely coupled design is one, where components does not bear complex assumptions while interacting with each other. For example, if we have two components say, a web-service and a scheduler, where web-service feeds the scheduler with some kind of data. In such scenario, the scheduler should not expect a particular order of data ie, assumption like, the first node will always hold the Primary ID and next node will holds the API name etc. Rather, it would be a wise choice to expect that where ever a Primary ID key is encountered, it is assumed to be holding Primary ID and so on. In such case, within the web service even if I change the order of my data, Scheduler need not change. Another good example could be in a web-application scenario, where, even if I change a database field my inteface component need not change. It is because, while designing the system I decided to create a component called Model. Which is positioned between Interface and my database layer, which takes care of data and always sends data in the same manner, irrespective of database structure, to the consumer component, which is interface in this case. So, we are no more concerned about the changes in one component effecting the other. So our initial effort pays later.
Please let me know, if you have some other view on this, and any feedback that you might have for me.
We all have read about tight and loose coupling. We all are aware that there exists two major type of couplings but, how many times did we try to depict and use the concept of loose coupling in our architecture? I am sure we are more driven towards tight coupling atleast practically. The reasons are:
1. Tight coupling is obvious option when scope of software application is small.
2. When development is required at rapid pace.
3. When debugging needs to be made easy for atleast new team members.
But, when this small application tries to add features and when complexity increases, we are often struck with evil called tight coupling. The reason?
The reason is straight forward. Each change in one component calls for changes in almost all other components, due to inter-dependency factor, known to us as tight coupling. It is because, each of our interacting components known more that what it needs, about the other component and hence, maintains some form of data or functionality dependency about the other component, with which it is interacting. This dependency obstructs our maintenance and feature building within our present architecture. And the intensity of evil increases when we add more new developers to the team. All new developers added, are hardly aware of already present complexity and their main aim is to some how manage, and get the feature working. This further accelerates the already complex situation.
When such situation arises, we are often seen compromising with many critical factors like: a) Optimization b) Resource utilization etc etc.
Then what is the way out?
The only way out is, while architecting a system always try to design a loosely coupled system. I agree, often during the initial phases, it will feel like a burden, from both architect and developers perspective. But, as an architect our aim is to NOT only think of present, but also of future. In most of the cases, we see that all system/application grows with time and hence desiging a loosly coupled system will always pay in long term.
But what exactly is loosely coupled design?
A loosely coupled design is one, where components does not bear complex assumptions while interacting with each other. For example, if we have two components say, a web-service and a scheduler, where web-service feeds the scheduler with some kind of data. In such scenario, the scheduler should not expect a particular order of data ie, assumption like, the first node will always hold the Primary ID and next node will holds the API name etc. Rather, it would be a wise choice to expect that where ever a Primary ID key is encountered, it is assumed to be holding Primary ID and so on. In such case, within the web service even if I change the order of my data, Scheduler need not change. Another good example could be in a web-application scenario, where, even if I change a database field my inteface component need not change. It is because, while designing the system I decided to create a component called Model. Which is positioned between Interface and my database layer, which takes care of data and always sends data in the same manner, irrespective of database structure, to the consumer component, which is interface in this case. So, we are no more concerned about the changes in one component effecting the other. So our initial effort pays later.
Please let me know, if you have some other view on this, and any feedback that you might have for me.
Labels: architecture, coupling, design
# posted by Technocrat @ 2:12 AM 
