Introduction
In my humble opinion component based development helps the developers in the maintance lifecycle of the product. this does not mean that the development time is longer. That totally depends on how you setup your development process. What I mean is that during development You need to think about the design and what are the components that you are going to build. Interesting part of this is, that you have to think before you start. In the maintenance mode it is easier. The code is organized, much smaller and dont forget the separation of concerns and contracting that allready should been dealth with.
One of the first questions that pops up, is on what level do I build components. A layer like the web, business or a persistence layer could allready be called a component. You can take this up to functionality that is a component inside for example a layer. It could be even a part of the functionality that becomes a component.
That the granuality of this design can give you a bit of a headache is obvious. You can see components as separate, individual working applications. This means that you have to package and assemble. Every component can be come for example a jar file and the application is nothing but an assembled puzzle of jar files dealing with the functionality as requested. The second option you have is: you dont package them but still create a fully working application and deal with the contracting part. This way you have embedded components. This is not very helpfull for distribution and standarisation. It also creates the pitfall that contracting and separation of concerns is neglected and in the end you still create god classes and the end product will be a moloch.
Why component based development
1. Flexibility
2 Re-usability
3. Maintainability
4. distribution of components.
5. standardization organization wide.
1. flexibility
The flexibility lies the most in the fact that it is a small independent application. It has its own contracts to deal with the outside world and it does only need things as property files that are defined inside of it. This makes it extremely adaptable to the outside world. Actually it is the other way around. The outside world is adapting to our component. The component has a contract and all it wants is us to follow that contract.
2. reusability
With the flexibility comes the reusabiltiy Here also counts that the world has to adapt to our litle component. As long everybody applies to the contract it can be used in any part of the application you like. You dont need to copy or duplicate it. If you want some extended code to do something else in a another part of the code, you just wright a piece of code that adapts to those wishes. Depending if it is part of the original functionality you add as part of the component or leave it outside.
3. Maintainability
The maintainability is in fact another item that is handled by the contracting and the piece of code being small.
The contracting part makes it easier because of the fact that the component is not depending on the state of the calling component. It only gets the desired data through te contract. So rebuilding our small component will have no effect on the the rest if of the code. Keep in mind, the only time that it effects the caller component, is because you changed the contract. I think that a small island of code in the case of maintainability speaks for it self.
4. Distrubtion of components
Why should we limit the bounderies of a component which is working indepedently to the borders of our first component build application. It is so easy to extract this component from its habitat and move it to another application. The only think you might want to take care of in this case is versioning. Different applications might not update at the same time. but that is quite easy solvable with toolings like maven and artifactory. Or any other tool you prefer.
5 standarisation organisation wide
If we continue the path of distrubution of components, then we can state that a component could be something that is used by every application in the compagny. Why should you build your own if it allready exists. That way we can standarize.
What are the pitfalls:
1. you have to come up with a good design.
2. It is necessary to follow up this design during development
3. discuss the parts that are grey area if it becomes part of layers
Think about transaction handling, remote connection handling etc..
4. unclear requirements or conflicts between usability or reusabilty
Conclusion:
In general I would say that the development of components based application can save time in development and maintenance. the trick is to design and set it up correctly. Take care of the pitfalls before you reach them. In follow up of faster development you will also have faster time to market.
Have fun!