Drupal Module Development vs Symfony and Laravel: How Modularity Really Works

Introduction

When developers talk about Drupal module development, they often assume that “modules” are a Drupal-only concept. However, modern PHP frameworks like Symfony and Laravel are also highly modular—just in different ways.

This article explains which aspects of modularity are used in Symfony and Laravel, how they compare to Drupal modules, and what this means in practice for developers building scalable, maintainable systems.

If you come from a Drupal background, this will help you better understand why Drupal feels the way it does—and how its architecture relates to the broader PHP ecosystem.

What Do We Mean by Modularity?

In software architecture, modularity means:

• The system is composed of independent building blocks
• Each block has clear responsibility
• Blocks communicate via contracts, not tight coupling
• Functionality can be extended without modifying core code

Drupal, Symfony, and Laravel all follow these principles—but implement them differently.

Drupal: Module-Centric Modularity

Drupal is fundamentally a plugin-based CMS. Modules are the primary unit of extensibility.

Key Modularity Features in Drupal

1. Modules as First-Class Citizens

A Drupal module:

• Can be enabled or disabled at runtime
• Declares dependencies (.info.yml)
• Integrates deeply with configuration, UI, routing, and storage

name: Custom Module
type: module
core_version_requirement: ^10 || ^11
dependencies:
  - node

Modules are not just code containers—they are behavioral extensions of the system.

2. Hook System (Legacy, but Still Relevant)

Hooks allow modules to alter or extend behavior:

function my_module_node_view(array &$build, NodeInterface $node) {
  // Alter node rendering
}

Pros

• Very powerful
• Zero configuration required

Cons

• Global namespace
• Weak typing
• Harder to trace

Hooks are gradually being replaced by services, events, and plugins.

3. Service-Based Architecture (Symfony Inside)

Modern Drupal modules define services:

services:
  my_module.order_processor:
    class: Drupal\my_module\Service\OrderProcessor
    arguments: ['@entity_type.manager']

This enables:

• Dependency Injection
• Testability
• Loose coupling

Drupal fully relies on Symfony’s DependencyInjection component.

4. Plugin API (Drupal’s Superpower)

Drupal provides a rich plugin system:

• Blocks
• Field types
• Formatters
• Conditions
• Migrate plugins
• Views plugins

/**
 * @Block(
 *   id = "example_block",
 *   admin_label = @Translation("Example block")
 * )
 */
class ExampleBlock extends BlockBase {}

This makes Drupal one of the most modular PHP systems ever built.

Symfony: Modularity Through Components and Contracts

Symfony takes a different approach. It does not focus on “modules” but on reusable building blocks.

1. Symfony Components (True Modularity)

Symfony is a collection of independent components:

• HttpFoundation
• Routing
• EventDispatcher
• DependencyInjection
• Console
• Validator

Each component can be installed separately:

composer require symfony/event-dispatcher

Key idea:

Symfony is modular at the library level, not the application feature level.

Drupal itself is built on these components.

2. Bundles (Historical Modular Units)

Symfony introduced Bundles as reusable application modules:

class BlogBundle extends Bundle {}

Bundles can contain:

• Controllers
• Services
• Event listeners
• Configuration

However, modern Symfony best practices discourage overusing bundles. Today:

• Composer packages + services are preferred
• Bundles are mainly used by reusable libraries

Important difference from Drupal:
Bundles organize code, but are not runtime-enabled features.

3. Events and Dependency Injection

Symfony encourages extension through:

• EventDispatcher
• Interfaces
• Dependency Injection

$dispatcher->dispatch(new UserRegisteredEvent($user));

This replaces hooks with:

• Strong typing
• Explicit contracts
• Predictable execution flow

Laravel: Modularity Through Service Providers and Packages

Laravel avoids the word “module” but is highly modular by design.

1. Service Providers: The Core of Modularity

Every feature in Laravel is bootstrapped through a Service Provider:

class BlogServiceProvider extends ServiceProvider {
  public function register() {}
  public function boot() {}
}

Service Providers:

• Register services
• Load routes
• Attach events
• Publish configs
• Register commands

👉 Closest analogue to a Drupal module entry point

2. Composer Packages as Feature Modules

Laravel encourages functionality to live in packages:

composer require spatie/laravel-permission

A package can include:

• Migrations
• Routes
• Middleware
• Views
• Config
• Commands

Packages are:

• Well isolated
• Easy to reuse
• Easily removable

3. Facades: Convenience Over Explicitness

Cache::get('key');

Facades provide static-like access to services.

Trade-off:

•  
  • Developer experience
• − Hidden dependencies

Drupal and Symfony favor explicit dependency injection instead.

Side-by-Side Comparison

Key Takeaways for Drupal Developers

• Drupal modules are feature-level extensions with UI, config, and storage
• Symfony components are low-level reusable libraries
• Laravel packages are feature modules bootstrapped via Service Providers

Drupal stands on Symfony’s architectural foundation but adds a powerful plugin-oriented CMS layer on top.

This explains why:

• Drupal feels heavier
• Drupal is extremely extensible
• Drupal scales well for complex content systems

Final Thoughts

Understanding how Symfony and Laravel approach modularity helps you:

• Write better Drupal modules
• Avoid anti-patterns
• Design cleaner service boundaries
• Communicate better with non-Drupal PHP teams

In short:

Symfony builds bricks.
Laravel assembles features.
Drupal builds ecosystems.

Next article One Feature, Three Approaches: Drupal Module vs Symfony vs Laravel