Component Driven Development: it's like Lego!

Did you ever hear about Component-Based Development? Maybe about Component Driven Development? Both concepts are the same, and if you’ve worked with Symfony, Spring or similar frameworks, then chances are you’ve already done Component Driven Development (CDD).

It’s all about separation of concerns. You design components with their own logic. Each component does one thing well and only one thing (that is also the Unix philosophy). Separating business logic in self-contained components requires to focus on interactions between components. In other words, you have to think in terms of interfaces and boundaries.

UML provides a component diagram that allows you to easily identify the components, interfaces and their relations. This could be a useful tool. In a UML component diagram, a provided interface is modeled using the lollipop notation and a required interface is modeled using the socket notation.

Simplified example of a UML component diagram

As I wrote previously, you are most likely already familiar with Component Driven Development if you know Symfony or Spring. Why? Because these two frameworks use the Inversion of Control (IoC) architectural pattern via the Dependency Injection design pattern (I consider IoC an architectural pattern because it’s not a design pattern you can implement).

There are two known issues with IoC, though. First, you need a way to manage dependencies between components. Second, how do you instantiate all these components (in which order for instance)? Dependency Injection Container (DIC) to the rescue! A (service) container requires some configuration that essentially describes the dependencies between components. Checkout the Symfony docs about Dependency Injection for more technical information.

With that, the two issues I just mentioned are solved and you can now write highly decoupled code. The main drawback is the time you’ll have to spend thinking about your architecture and component interactions. This is where the UML component diagram can be helpful ;-)

Thanks to a framework that provides abstractions such as a DIC, you can start “assembling” an app by reusing existing components (i.e. libraries) to avoid writing everything from scratch. See why it is like Lego now?

In the PHP world, we have magic tools like:

• The Symfony components: a reusable set of standalone PHP components
• Composer: the awesome package manager for PHP
• Packagist: the official registry to discover great PHP libraries

Less time wasted writing “framework code”, more time spent writing business-oriented code and “glue code” for the existing components you use directly “as-is”, yay!