What is Component-Driven Development?

Question

Component-Driven Development term is starting to get used widely, esp. in connection with Inversion of Control.

1. What is it?
2. What problems does it solve?
3. When is it appropriate and when not?

Answer 1

I am not sure it is a "widespread" terminology, but in VCS (Version Control System), I know of two ways to manage a set of files needed to build a program:

• system-based approach, where the all set has a common life cycle and must be tagged as a all
• component-based approach, where individual set of files have their own life cycle, and where a meta-label references all the labels of the components to designate the all system by composition and dependencies between those components.

The applicative architecture is used to identify those components:

• functional domain and applications
• third party libraries
• frameworks

That is where IoC comes in, since it is at the base of any framework. The problem it solves is allow you to better identify the part of your application:
Suppose you design a PLR (Profit and Loss) application, in charge to compute the gain and losses (position) of a trader.
You would quickly realize it is not a single application, but a composition of several:

• GUI
• launcher
• dispatcher (to dispatch the computation across several server, because one would not have enough memory to compute all!)
• and so forth

You can then identify a computation framework (Ioc) which would enable you to plug-in your different modules, which then are called at the right time by your framework.

Or you can identify purely technical frameworks (KPI, logs, exception managements) which can then be used by any of your other functional components.

In term of project management, that also allows you to develop each part independently, while assuring a global coordination through the VCS.

Answer 2

Here's my definition after doing some research.

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 usually 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.

Related links:

• Component-Driven Development and IoC Container

Answer 3

What is it?

Rinat, I think the definition in your answer covers this question well. Although, I question why the definition includes that a component needs to explicitly define its dependencies. A canonical example of a component is an ActiveX control - do they need to explicitly define their dependencies?

What problems does it solve?

Management of complexity. It seeks to address that by allowing you to only ever think about the implementation of the component. One should only need to author components, one should not to have to think about how to combine or manage them. That is done by some framework or infrastructure external to the component, and unimportant to the component author.

When is it appropriate and when not?

Not necessarily appropriate in a trival or throw-away application. The bad smell in a component architecture, is if you are spending time on thinking or working on the infrastructure to manage and combine components, rather than the components themselves.

Answer 4

If you're interested in combining components (or other reusable assets) into applications you should also take a look at the software product lines methodology.

In a software product line the dependencies between components (or lower-level code elements) are explicitly managed outside those components. This is typically done using a feature model that contains rules such as

• These two components must not be used together (mutual exclusivity)
• If this component is used then this other component must be used or (interdependency)
• Any combination of some specified set of components may be used (optionality)

Other more complex rules are possible depending on the complexity of the dependencies you wish to model.

Another approach that is sometimes used instead of feature modelling is to use a code generator to configure the different components that are to be assembled into the finished application. It's also possible to combine feature modelling with code generation.

Aside from Code Generation, some other terms you might search for as domain-specific modelling, model-driven software development, software family.