From SOLID to Composition, Dependency Injection, and IoC: How Angular, Spring, and Node.js Differ

When learning Angular, Spring, and Node.js, I often came across terms like SOLID, Dependency Injection (DI), Inversion of Control (IoC), IoC Container, and Composition.

At first, these concepts can feel like they are all the same thing. They are not.

The key realization is:

SOLID is about how we design software. Composition is about how we build larger systems from smaller pieces. Dependency Injection is a technique for providing those pieces. IoC containers automate that process.

Understanding this relationship makes Angular, Spring, and Node.js architectures much easier to reason about.

1. SOLID Is a Design Principle, Not a Framework Feature

SOLID is a collection of software design principles.

For example, Single Responsibility Principle (SRP) says that a component should have a focused responsibility.

Instead of having one class responsible for HTTP handling, database access, validation, email, and payment processing, we can separate those responsibilities:

Controller
    ↓
Service
    ↓
Repository
    ↓
Database

Each part has a focused job.

Similarly, the Open/Closed Principle (OCP) encourages us to design components that can be extended without constantly modifying their existing implementation.

These principles don't require Angular, Spring, or an IoC container.

You can follow SOLID in plain JavaScript.

2. Composition Is the Bigger Idea

Composition means:

Build a larger behavior by combining smaller, focused pieces.

This works in both functional and object-oriented programming.

In functional programming:

function A
    ↓
function B
    ↓
function C

A larger function can be created by composing smaller functions.

In object-oriented programming:

OrderService
    │
    ├── PaymentService
    └── EmailService

OrderService is composed using other objects.

The important relationship is often:

HAS-A rather than IS-A

For example:

OrderService HAS-A PaymentService

rather than:

OrderService IS-A PaymentService

This is one reason composition is often preferred over deep inheritance hierarchies.

3. Dependency Injection Is a Way of Doing Composition

Consider this:

class OrderService {
  constructor(private paymentService: PaymentService) {}
}

OrderService needs PaymentService.

Instead of creating it internally:

class OrderService {
  constructor() {
    this.paymentService = new PaymentService();
  }
}

we provide it from outside:

const paymentService = new PaymentService();
const orderService = new OrderService(paymentService);

This is Dependency Injection.

The dependency is injected into the object instead of the object creating the dependency itself.

So DI helps us build a loosely coupled composition.

4. IoC Is the Bigger Concept

Normally, our code controls object creation:

Application code
      ↓
creates Service
      ↓
creates Repository
      ↓
creates Database

With IoC, that control is moved somewhere else.

For example, Angular or Spring can control object creation and dependency resolution:

Application
     ↓
"I need OrderService"
     ↓
IoC Container
     ↓
resolves PaymentService
     ↓
resolves Repository
     ↓
creates OrderService

That's Inversion of Control.

The framework is now controlling the creation and wiring instead of our application code doing everything manually.

5. Angular's IoC Container

Angular provides a Dependency Injection system.

Suppose we have:

@Injectable()
class UserService {
}

and:

@Component(...)
class UserComponent {
  constructor(private userService: UserService) {}
}

The component only declares:

"I need a UserService."

It doesn't say:

new UserService()

Angular's injector resolves the dependency.

Conceptually, Angular can build something like:

UserComponent
      ↓
UserService
      ↓
UserRepository
      ↓
HttpClient

Angular's DI system manages this dependency graph.

So a useful mental model is:

Angular DI is Angular's mechanism for implementing IoC.

Angular also has hierarchical injectors, which allow dependencies to exist at different scopes such as the application/root level or component level.

6. Spring's IoC Container

Spring follows a similar idea in Java.

Instead of manually doing:

UserRepository repository = new UserRepository();
UserService service = new UserService(repository);
UserController controller = new UserController(service);

Spring can manage these objects as beans and inject their dependencies.

Conceptually:

Spring IoC Container
        ↓
UserRepository
        ↓
UserService
        ↓
UserController

Spring therefore takes responsibility for constructing and wiring the object graph.

This is why the term IoC Container is so commonly associated with Spring.

7. What About Node.js?

Node.js itself does not provide an Angular/Spring-style IoC container.

But that doesn't mean Node.js cannot follow SOLID or use Dependency Injection.

You can simply do it manually.

class UserService {
  constructor(repository) {
    this.repository = repository;
  }
}

Then the application's composition root can wire everything:

const repository = new UserRepository();
const service = new UserService(repository);
const controller = new UserController(service);

The dependency graph is:

UserRepository
      ↓
UserService
      ↓
UserController

This is still DI and composition.

The difference is that you are performing the wiring yourself.

Node.js gives you modules and functions/classes that allow you to structure the application, but it doesn't automatically construct your dependency graph.

8. Why Functional Programming Often Doesn't Need an IoC Container

This was one of the most interesting differences.

In functional programming, dependencies are often passed directly as function arguments.

For example:

function calculateTotal(cart, taxService) {
  const tax = taxService.calculate(cart);
  return cart.total + tax;
}

The dependency is explicit:

calculateTotal
      ↑
  taxService

We can provide a different implementation:

calculateTotal(cart, realTaxService);

or:

calculateTotal(cart, fakeTaxService);

No IoC container is required.

This is still dependency injection.

The difference is that functional programming often prefers explicit composition rather than a framework-managed dependency graph.

9. React Uses Composition Heavily

React is primarily based around functions and component composition.

Instead of a large class hierarchy, we can build:

Dashboard
 ├── Header
 ├── Sidebar
 ├── UserProfile
 ├── Orders
 └── Notifications

The Dashboard component is composed from smaller components.

Dependencies can also be passed through props:

App
 ↓
UserComponent
 ↓
userService

React also has Context, which allows values to be made available to components in a subtree.

Context can look somewhat similar to dependency injection, but it is not the same kind of general-purpose IoC container provided by Angular or Spring.

10. Composition vs Dependency Injection vs IoC

The relationship can now be summarized:

SOLID
  │
  ├── Design principles
  │
  └── Encourage loose coupling
          │
          ▼
      Composition
          │
          └── Build larger systems from smaller pieces
                    │
                    ▼
             Dependency Injection
                    │
                    └── Provide dependencies from outside
                              │
                              ▼
                       IoC Container
                              │
                              └── Automates dependency creation/wiring

These aren't competing concepts.

They operate at different levels.

11. The Same Architecture, Different Approaches

Consider:

Controller
    ↓
Service
    ↓
Repository

Manual Node.js

You create everything
        ↓
You inject dependencies
        ↓
You control composition

Angular

Angular Injector
        ↓
Creates dependencies
        ↓
Injects them
        ↓
Manages scopes

Spring

Spring IoC Container
        ↓
Creates beans
        ↓
Resolves dependencies
        ↓
Injects them

Functional approach

Functions
    ↓
Explicit arguments
    ↓
Composition

The underlying architectural goal can be the same:

Keep responsibilities separate and dependencies replaceable.

The mechanism is different.

12. The Most Important Mental Model

The biggest lesson is that SOLID does not require DI, and DI does not require an IoC container.

You can write SOLID JavaScript without any framework.

You can perform DI manually:

const repository = new UserRepository();
const service = new UserService(repository);

You can then introduce an IoC container when manually managing a large dependency graph becomes cumbersome.

So the hierarchy I now use to understand these concepts is:

SOLID
  ↓
How should I design my components?

Composition
  ↓
How should I combine those components?

Dependency Injection
  ↓
How should I provide their dependencies?

IoC
  ↓
Who should control object creation?

IoC Container
  ↓
Can a framework automate that control?

Once this distinction is clear, Angular, Spring, Node.js, and functional frameworks stop looking like completely different architectural worlds.

They are often solving the same fundamental problem:

How do we build a large system from small, independent pieces without tightly coupling everything together?

They simply choose different mechanisms for doing it.