What is Component-Driven Development?

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?

What is it?

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.

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.

Component-Based Development is nothing really new. I don't know of Component-Driven Development, but I am going to assume it's CBD. It's how Unix is designed, bunch of substitutable small programs each doing one thing very well. In desktop arena, Delphi's VCL has been successful at using components with rich reusable components and third party market like no other. We are now seeing the revival of the CBD as some technologies are maturing. For example simple web apps are evolving to SOA and RESTful WS. All Java guys been talking about is modularity and IoC.

The answer you are looking for likely will be found in Why and what of Inversion of Control by Ke Jin.

Besides, the imperative natural of these classic OO programming languages tend to miss the forest (high-level architectures/structures) for the trees (low-level logic control procedural code). Development and maintenance engineers taking over an existing application have to rely on its out of date design/architecture documents and low level code comments/patterns.

The component-based development (CBD) paradigm tackles the two issues above by shifting plumbing logic into frameworks that manipulate components and set up applications based on users/developers provided declarative descriptions. Contrary to the common confusion, such declarative descriptions are not meant to be application setup scripts. Rather, their fundamental intention is to explicitly express application architectures/structures without mandating their imperative plumbing procedures (namely describe the what instead of the how). The goal of CBD paradigm is to support effective and flexible application compositions by these frameworks and having application developers focus on business logic and domain issues without concerning low-level plumbing complexities.

CBD frameworks that combine the declarative application descriptions and the IoC technique are referred to as IoC frameworks. Contrary to their predecessors, IoC frameworks are non-invasive and use the dependency/configuration injection/setting scenario.

According to Wikipedia, Component-Based Development is an alias for Component-based software engineering (CBSE).

[It] is a branch of software engineering, the priority of which is the separation of concerns in respect of the wide-ranging functionality available throughout a given software system.

This is somewhat vague, so let's look at more details.

An individual component is a software package, or a module, that encapsulates a set of related functions (or data).

All system processes are placed into separate components so that all of the data and functions inside each component are semantically related (just as with the contents of classes). Because of this principle, it is often said that components are modular and cohesive.

So, according to this definition, a component can be anything as long as it does one thing really well and only one thing.

With regards to system-wide co-ordination, components communicate with each other via interfaces. [...] This principle results in components referred to as encapsulated.

So this is sounding more and more like what we think of good API or SOA should look like.

The provided interfaces are represented by a lollipop and required interfaces are represented by an open socket symbol attached to the outer edge of the component in UML.

_{(source: wikimedia.org)}

Another important attribute of components is that they are substitutable, so that a component could be replaced by another (at design time or run-time), if the requirements of the initial component (expressed via the interfaces) are met by the successor component.

Reusability is an important characteristic of a high quality software component. A software component should be designed and implemented so that it can be reused in many different programs.

Substitutability and reusability is what makes a component a component. So what's the difference between this and Object-Oriented Programming?

The idea in object-oriented programming (OOP) is that software should be written according to a mental model of the actual or imagined objects it represents. [...]

Component-based software engineering, by contrast, makes no such assumptions, and instead states that software should be developed by gluing prefabricated components together much like in the field of electronics or mechanics.

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