Rinat Abdullin

Component-Driven Development is an approach in software development in which code is fragmented into reusable and testable components that are combined together to form application foundation for delivering business functionality. The combination and management of components is generally delegated to Inversion of Control Container.

A component itself is a class that implements some service contract and explicitly defines the dependencies that it needs in order to fulfill this contract. Actual implementation is hidden from everybody else outside the component.

Component-driven development really helps to deliver multiple applications and systems efficiently. It happens because:

• important functionality is abstracted in components;
• components are coded and unit-tested only once;
• it is easy to reuse component in similar situations, reducing development effort and avoiding code duplication;
• every component has multiple use cases that provide additional feedback and help to find problems or limitations, if there are any;
• whenever a component is fixed or improved, all its consumers would benefit from that automatically.

Multiple components can have rather complex relations. Thus, visualizing them makes application a bit simpler to understand.

As we go up in the complexity of the development, it becomes too cumbersome to manage components on the individual basis. That's where infrastructure shards come into the play. Infrastructure shard is a group of components used together in a similar manner to deliver certain functionality across multiple applications.

This scenario creates additional benefits for the component-driven development. Some synergy effects might include:

• Business functionality could be used to extend multiple applications. Since UI is shared, we could use shared documentation, tutorials and screenshots as well.
• Sometimes context requires infrastructure shard to be evolved. This brings potential improvements in all existing and new applications.
• When a group of components is developed to be used in multiple scenarios from the start, this polishes the overall design even further than TDD or CDD would alone.
• Localization or UI changes across the software product line become easier, since the effort does not have to be duplicated and tested in multiple codebases.

Related links:

• Component-Driven Development and IoC Containers
• Developing Component-Driven Applications powered by IoC Containers
• Infrastructure Shards and Optional Components
• Visualize IoC Container and Domain Dependencies
• What is Component-Driven Development on Stack Overflow