What Is Dip - Learning Module

Loading content...

0/246

Traditional vs Inverted Dependencies

Two Architectures, Radically Different Outcomes

Every software system has dependencies. The question isn't whether modules depend on each other — they must — but which direction those dependencies point. This seemingly subtle structural choice has profound implications for how your system evolves, how easily it can be tested, and how gracefully it handles change.

In this page, we'll conduct a detailed side-by-side comparison of traditional dependency structures versus DIP-compliant inverted dependencies. We'll trace through concrete examples showing exactly what changes, why it matters, and how to recognize each pattern in real codebases.

What You Will Learn

By the end of this page, you will understand exactly how traditional dependencies work, why they cause problems, how dependency inversion transforms the structure, and how to visualize and verify the dependency direction in your own systems. You'll be able to draw both architectures and explain the differences to colleagues.

The Traditional Dependency Structure

In traditional software architecture, dependencies flow naturally from high-level to low-level. This seems intuitive: the business logic uses the database, so it depends on the database module. Let's examine this structure in detail.

The Natural Flow:

When developers think about layers, they typically imagine something like this:

┌─────────────────────────────────────────────────┐
│           PRESENTATION LAYER                    │
│      (Controllers, Views, API Endpoints)        │
│                                                 │
│         import { OrderService }                 │
└───────────────────────┬─────────────────────────┘
                        │
                        │ depends on (imports)
                        ▼
┌─────────────────────────────────────────────────┐
│           BUSINESS LOGIC LAYER                  │
│      (Services, Domain Logic, Use Cases)        │
│                                                 │
│         import { OrderRepository }              │
└───────────────────────┬─────────────────────────┘
                        │
                        │ depends on (imports)
                        ▼
┌─────────────────────────────────────────────────┐
│           DATA ACCESS LAYER                     │
│      (Repositories, Database Access)            │
│                                                 │
│         import { Pool } from 'pg'               │
└───────────────────────┬─────────────────────────┘
                        │
                        │ depends on (imports)
                        ▼
┌─────────────────────────────────────────────────┐
│           DATABASE DRIVER                       │
│      (pg, mysql, mongodb, etc.)                 │
└─────────────────────────────────────────────────┘

Dependencies cascade downward. Each layer imports from the layer below. This feels natural because it mirrors the runtime call flow: a request arrives at the controller, which calls the service, which calls the repository, which calls the database.

The Source Code Reality:

Let's look at actual code in a traditional architecture:

traditional-architecture.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
// ═══════════════════════════════════════════════════════════════════
// 📦 data-access/order-repository.ts
// The Data Access layer — knows about PostgreSQL specifics
// ═══════════════════════════════════════════════════════════════════
 
import { Pool } from 'pg';  // Database driver
 
export class OrderRepository {
    constructor(private pool: Pool) {}
 
    async findById(id: string): Promise<Order | null> {
        const result = await this.pool.query(
            'SELECT * FROM orders WHERE id = $1',
            [id]
        );
        return result.rows[0] ? this.mapToOrder(result.rows[0]) : null;
    }
 
    async save(order: Order): Promise<void> {
        await this.pool.query(
            'INSERT INTO orders (id, customer_id, status, total) VALUES ($1, $2, $3, $4)',
            [order.id, order.customerId, order.status, order.total]
        );
    }
 
    async findPendingOrders(): Promise<Order[]> {
        // PostgreSQL-specific: Using array aggregation
        const result = await this.pool.query(`
            SELECT o.*, array_agg(oi.product_id) as product_ids
            FROM orders o
            LEFT JOIN order_items oi ON o.id = oi.order_id
            WHERE o.status = 'pending'
            GROUP BY o.id
        `);
        return result.rows.map(row => this.mapToOrder(row));
    }
}
 
// ═══════════════════════════════════════════════════════════════════
// 📦 business-logic/order-service.ts  
// The Business Logic layer — DIRECTLY depends on OrderRepository
// ═══════════════════════════════════════════════════════════════════
 
import { OrderRepository } from '../data-access/order-repository';  // ❌ Direct coupling
 
export class OrderService {
    constructor(private orderRepository: OrderRepository) {}
    //                    ^^^^^^^^^^^^^^^^
    //                    Depends on concrete class, not abstraction
 
    async processOrder(orderId: string): Promise<ProcessingResult> {
        const order = await this.orderRepository.findById(orderId);
        if (!order) {
            return { success: false, error: 'Order not found' };
        }
 
        // Business logic here...
        order.status = 'processing';
        await this.orderRepository.save(order);
 
        return { success: true };
    }
}
 
// ═══════════════════════════════════════════════════════════════════
// 📦 presentation/order-controller.ts
// The Presentation layer — depends on OrderService
// ═══════════════════════════════════════════════════════════════════
 
import { OrderService } from '../business-logic/order-service';
 
export class OrderController {
    constructor(private orderService: OrderService) {}
 
    async handleProcessOrder(req: Request, res: Response) {
        const result = await this.orderService.processOrder(req.params.orderId);
        if (result.success) {
            res.json({ message: 'Order processed' });
        } else {
            res.status(400).json({ error: result.error });
        }
    }
}

The Problem Hides in the Imports

Look at the import statements. OrderService imports from '../data-access/order-repository'. This means the business logic layer has a source code dependency on the data access layer. If OrderRepository changes, OrderService may need to change. If the data access layer is in a different package, business logic can't compile without it.

Problems with the Traditional Structure

The traditional dependency structure creates several interrelated problems that compound as systems grow:

Problem 1: Change Propagation

In the traditional structure, changes flow upward — the opposite of what we want:

Database schema change
        ↓ forces
OrderRepository method signature change
        ↓ forces  
OrderService modification
        ↓ forces
OrderController adjustment
        ↓ forces
API response format change

A low-level change in the database schema can cascade all the way to the API. This is exactly backwards — we want stable high-level components and volatile low-level components, but here infrastructure changes corrupt business logic.

Concrete Example:

Suppose you switch from PostgreSQL's array_agg to JSON aggregation for better performance:

-- Old query (in OrderRepository)
SELECT array_agg(oi.product_id) as product_ids...

-- New query (PostgreSQL-specific optimization)
SELECT json_agg(json_build_object('id', oi.product_id, 'qty', oi.quantity)) as items...

This changes the return type from string[] to a JSON structure. Suddenly OrderService needs modification to handle the new format — even though nothing about order processing logic changed.

Problem 2: Testing Difficulty

To test OrderService in the traditional structure, you need a real OrderRepository, which needs a real PostgreSQL database:

// Testing OrderService traditionally requires:
// 1. Spinning up a PostgreSQL instance (Docker, local install, etc.)
// 2. Running migrations to create the orders table
// 3. Seeding test data
// 4. Cleaning up after each test

it('should process order', async () => {
    // Complex setup required...
    const pool = new Pool({ connectionString: 'postgresql://...' });
    const repo = new OrderRepository(pool);
    const service = new OrderService(repo);  // Tied to real database

    // Test is now slow, flaky, and requires infrastructure
    const result = await service.processOrder('order-123');
});

This makes tests slow, brittle (network issues, concurrent tests), and hard to set up in CI pipelines. Many teams skip testing business logic or write minimal tests due to this friction.

Problem 3: Vendor Lock-in

The OrderService is permanently married to PostgreSQL:

import { OrderRepository } from '../data-access/order-repository';
//     └─────────────────────────────────────────────────────┘
//     This import KNOWS there's a PostgreSQL-based repository

Want to switch to MongoDB? You can't just swap implementations — you need to:

Create a new MongoOrderRepository
Modify OrderService to import from the new location
Update all tests that reference the import
Hope the interfaces match (they probably don't)

Problem 4: Parallel Development Barriers

Teams can't work independently:

The database team can't change repository internals without coordinating with the service team
The service team is blocked if the repository isn't ready
Everyone touches the same files during integration

Summary of Traditional Dependency Problems

•Upward change propagation — Infrastructure changes force business logic changes
•Testing requires infrastructure — Can't test services without real databases
•Technology lock-in — Switching databases means rewriting services
•No independent deployment — Layers are welded together
•Team coupling — Different teams can't work in parallel without coordination
•Reuse impossibility — Business logic can't be extracted to different projects

The DIP-Compliant Inverted Structure

Now let's see how DIP transforms this architecture. The key insight is that we introduce abstractions owned by higher-level modules and make lower-level modules depend on those abstractions.

The Inverted Flow:

┌─────────────────────────────────────────────────┐
│           BUSINESS LOGIC LAYER                  │
│      (Services, Domain Logic, Use Cases)        │
│                                                 │
│   DEFINES: interface OrderRepository { ... }    │ ←── Abstraction lives HERE
│   USES: this.orderRepository.findById(id)      │
└───────────────────────┬─────────────────────────┘
                        │
                        │ depends on (import flows TO here)
                        │
┌───────────────────────┴─────────────────────────┐
│           ABSTRACTION BOUNDARY                  │
│   OrderRepository interface (CONTRACT)          │
│   Owned by Business Logic, not Data Access      │
└───────────────────────┬─────────────────────────┘
                        ▲
                        │ implements (import flows FROM here)
                        │
┌───────────────────────┴─────────────────────────┐
│           DATA ACCESS LAYER                     │
│      (Concrete Repository Implementations)      │
│                                                 │
│   import { OrderRepository }                    │
│       from '../business-logic/ports'            │
│   class PostgresOrderRepository                 │
│       implements OrderRepository { ... }        │
└───────────────────────┬─────────────────────────┘
                        │
                        │ depends on
                        ▼
┌─────────────────────────────────────────────────┐
│           DATABASE DRIVER                       │
└─────────────────────────────────────────────────┘

The Critical Difference:

Notice that the arrow between Business Logic and Data Access now points upward (from Data Access toward Business Logic). The data access layer implements an interface defined in the business logic layer. This is the inversion.

The Transformed Source Code:

inverted-architecture.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
// ═══════════════════════════════════════════════════════════════════
// 📦 business-logic/ports/order-repository.ts
// The ABSTRACTION — defined in business logic, expresses domain needs
// ═══════════════════════════════════════════════════════════════════
 
// No database imports here! Pure domain concepts.
export interface OrderRepository {
    findById(id: string): Promise<Order | null>;
    save(order: Order): Promise<void>;
    findPendingOrders(): Promise<Order[]>;
}
 
// Domain types — no infrastructure leaking in
export interface Order {
    id: string;
    customerId: string;
    status: OrderStatus;
    total: Money;
    items: OrderItem[];
}
 
// ═══════════════════════════════════════════════════════════════════
// 📦 business-logic/order-service.ts
// The Business Logic — uses the abstraction it OWNS
// ═══════════════════════════════════════════════════════════════════
 
import { OrderRepository, Order } from './ports/order-repository';
//                          ↑
//                          Importing from SAME layer (business-logic)
//                          NOT from data-access layer
 
export class OrderService {
    constructor(private orderRepository: OrderRepository) {}
    //                    ^^^^^^^^^^^^^^^^
    //                    Interface type, not concrete class
 
    async processOrder(orderId: string): Promise<ProcessingResult> {
        const order = await this.orderRepository.findById(orderId);
        if (!order) {
            return { success: false, error: 'Order not found' };
        }
 
        // Business logic remains unchanged regardless of database
        order.status = 'processing';
        await this.orderRepository.save(order);
 
        return { success: true };
    }
}
 
// ═══════════════════════════════════════════════════════════════════
// 📦 data-access/postgres/postgres-order-repository.ts
// The concrete implementation — IMPORTS from business logic
// ═══════════════════════════════════════════════════════════════════
 
import { Pool } from 'pg';
import { OrderRepository, Order } from '../../business-logic/ports/order-repository';
//                                              ↑
//                                              Data Access imports FROM Business Logic!
//                                              This is the INVERSION.
 
export class PostgresOrderRepository implements OrderRepository {
    constructor(private pool: Pool) {}
 
    async findById(id: string): Promise<Order | null> {
        const result = await this.pool.query(
            'SELECT * FROM orders WHERE id = $1',
            [id]
        );
        return result.rows[0] ? this.mapToOrder(result.rows[0]) : null;
    }
 
    async save(order: Order): Promise<void> {
        await this.pool.query(
            'INSERT INTO orders (id, customer_id, status, total) VALUES ($1, $2, $3, $4)',
            [order.id, order.customerId, order.status, order.total]
        );
    }
 
    async findPendingOrders(): Promise<Order[]> {
        // PostgreSQL-specific implementation hidden from business logic
        const result = await this.pool.query(`
            SELECT o.*, json_agg(...) as items FROM orders o ...
        `);
        return result.rows.map(row => this.mapToOrder(row));
    }
 
    private mapToOrder(row: any): Order {
        // Mapping from database row to domain Order
        // This translation is encapsulated here
    }
}
 
// ═══════════════════════════════════════════════════════════════════
// 📦 data-access/mongodb/mongo-order-repository.ts
// An ALTERNATIVE implementation — same interface, different technology
// ═══════════════════════════════════════════════════════════════════
 
import { Collection } from 'mongodb';
import { OrderRepository, Order } from '../../business-logic/ports/order-repository';
 
export class MongoOrderRepository implements OrderRepository {
    constructor(private collection: Collection) {}
 
    async findById(id: string): Promise<Order | null> {
        return this.collection.findOne({ _id: id }) as Promise<Order | null>;
    }
 
    async save(order: Order): Promise<void> {
        await this.collection.updateOne(
            { _id: order.id },
            { $set: order },
            { upsert: true }
        );
    }
 
    async findPendingOrders(): Promise<Order[]> {
        return this.collection.find({ status: 'pending' }).toArray() as Promise<Order[]>;
    }
}

The Import Direction Is Everything

In the inverted structure, PostgresOrderRepository imports from '../../business-logic/ports/order-repository'. The data access layer reaches up to get the interface definition from business logic. This means business logic has zero knowledge of data access existence. It can compile, test, and run without any database code.

Side-by-Side Comparison

Let's directly compare the two structures across multiple dimensions:

Traditional vs Inverted Dependencies
Aspect	Traditional	Inverted (DIP)
Interface location	In data access layer or none	In business logic layer
Business logic imports from	Data access layer	Own ports/interfaces package
Data access imports from	Database driver only	Business logic interfaces + driver
Compile-time dependency flow	High → Low	Low → High (to abstractions)
Runtime flow	High → Low	High → Low (unchanged)
Switching implementations	Modify business logic imports	Swap injection, no business logic changes
Testing business logic	Requires real database	Mock interface, no database needed
Adding new database	Create repo, update all imports	Create repo implementing interface, done

Traditional Structure

•Business logic → Data access
•Changes propagate upward
•Tests need infrastructure
•Technology decisions leak into domain
•Replacing components = surgery

Inverted Structure (DIP)

•Data access → Business logic abstractions
•Changes stay contained in implementations
•Tests use simple mocks/stubs
•Domain is pure and portable
•Replacing components = plugin swap

Visual Representation — Package Dependencies:

TRADITIONAL:                          INVERTED (DIP):

┌──────────────┐                      ┌──────────────┐
│  controller  │                      │  controller  │
└──────┬───────┘                      └──────┬───────┘
       │                                     │
       ▼                                     ▼
┌──────────────┐                      ┌──────────────┐
│   service    │──────────┐           │   service    │◄─────────┐
└──────┬───────┘          │           └──────────────┘          │
       │                  │                  ▲                  │
       ▼  import          │                  │ import           │
┌──────────────┐          │           ┌──────┴───────┐          │
│ repository   │          │           │  repository  │          │
│  (concrete)  │          │           │  (interface) │          │
└──────┬───────┘          │           └──────────────┘          │
       │                  │                  ▲                  │
       ▼                  │                  │ implements       │
┌──────────────┐          │           ┌──────┴───────┐          │
│   pg driver  │          │           │   postgres   │──────────┘
└──────────────┘          │           │    impl      │
                          │           └──────┬───────┘
 Dependencies flow        │                  │
 DOWNWARD only            │                  ▼
                          │           ┌──────────────┐
                          │           │   pg driver  │
                          │           └──────────────┘
                          │   
                          │           Dependencies flow TOWARD
                          │           abstractions (owned by service)

The Inversion in Action: A Complete Scenario

Let's walk through a realistic scenario to see how these structures behave differently.

Scenario: Your company decides to migrate from PostgreSQL to Amazon DynamoDB for the orders database. How does each architecture handle this?

Traditional Architecture — The Migration Nightmare:

Step 1: Create DynamoOrderRepository
        → New file with DynamoDB SDK code

Step 2: Modify OrderService to import DynamoOrderRepository
        → Change: import { DynamoOrderRepository } from '../data-access/dynamo-order-repository'
        → Risk: What if the interfaces don't match exactly?
        → Risk: Type changes may cascade into service logic

Step 3: Update OrderService constructor
        → Change: constructor(private repo: DynamoOrderRepository)
        → All callers need to change how they construct OrderService

Step 4: Find all places OrderService is instantiated
        → Controllers, factories, tests, integration tests
        → Each one needs modification

Step 5: Update all tests for OrderService
        → They expected PostgresOrderRepository
        → Now they need DynamoDB setup
        → Or complex mocking of concrete DynamoDB class

Step 6: Hope nothing breaks during integration
        → High risk — many files modified
        → Hard to test incrementally
        → Big-bang deployment

Files modified: 15-30+
Risk level: High
Rollback difficulty: Extremely difficult

Inverted Architecture — The Smooth Migration:

Step 1: Create DynamoOrderRepository implementing OrderRepository interface
        → New file with DynamoDB SDK code
        → Implements EXISTING interface from business logic
        → No other files change yet

Step 2: Write tests for DynamoOrderRepository in isolation
        → Verify it conforms to the interface contract
        → Use DynamoDB local or mocks
        → Business logic tests still pass (unchanged)

Step 3: Update composition root / dependency injection config
        → ONE place where repositories are bound to interfaces
        → Change: bind(OrderRepository).to(DynamoOrderRepository)
        → Or: factory.createOrderRepository = () => new DynamoOrderRepository(...)

Step 4: Deploy and verify
        → OrderService unchanged — depends only on interface
        → Controllers unchanged — depends only on OrderService
        → Tests unchanged — already use interface mocks

Files modified: 2-3 (new implementation + composition configuration)
Risk level: Low
Rollback difficulty: Change one configuration line

Database Migration Comparison
Aspect	Traditional	Inverted
New files created	1 (new repository)	1 (new repository)
Existing files modified	15-30+	1-2 (config only)
Business logic modified	Yes	No
Tests needing updates	All service tests	None (except new repo tests)
Can run both implementations	Very difficult	Easy (feature flag)
Risk of regression	High	Very low
Rollback process	Reverse all changes	Change config line
Incremental migration possible	Not really	Yes (gradual traffic shifting)

The Power of the Inversion

With DIP, infrastructure changes become plugin swaps rather than surgery. The business logic is insulated from these changes because it never knew about the specific implementation in the first place. This is the practical payoff of dependency inversion.

Runtime vs Compile-Time Dependencies

A critical subtlety of DIP is the distinction between compile-time (source code) dependencies and runtime dependencies. DIP inverts compile-time dependencies while leaving runtime behavior unchanged.

Runtime (Execution) Flow:

At runtime, the actual execution flow is identical in both architectures:

Request arrives
    ↓
Controller.handleRequest()
    ↓
OrderService.processOrder()
    ↓
PostgresOrderRepository.findById()  (or DynamoOrderRepository)
    ↓
Database query executed
    ↓
Results flow back up the stack

The controller calls the service, which calls the repository, which calls the database. This is true whether or not DIP is applied. DIP doesn't change how the code executes.

Compile-Time (Source Code) Dependencies:

What DIP changes is which modules need to know about which other modules at compile time:

TRADITIONAL (compile-time dependencies):

OrderController.ts
    ├── imports OrderService.ts
    │       ├── imports PostgresOrderRepository.ts
    │       │       └── imports pg (database driver)
    │       └── transitively knows about PostgreSQL
    └── transitively depends on entire stack


INVERTED (compile-time dependencies):

OrderController.ts
    └── imports OrderService.ts
            └── imports OrderRepository.ts (interface only)
                    └── knows NOTHING about PostgreSQL

PostgresOrderRepository.ts
    ├── imports OrderRepository.ts (interface from business layer)
    └── imports pg (database driver)

In the inverted structure, OrderService can be compiled without ANY knowledge of PostgreSQL. It only knows the interface. The PostgreSQL implementation is a separate compilation unit that conforms to that interface.

The Inversion Is a Compile-Time Concept

DIP reorganizes source code dependencies, not runtime behavior. At runtime, OrderService still calls PostgresOrderRepository methods. But at compile time, OrderService knows nothing about PostgreSQL — it only knows the abstraction. This is what enables independent compilation, testing, and deployment.

Practical Implications:

Independent Compilation: Business logic can be compiled into a JAR/package without any database dependencies
Parallel Development: Teams can work on different implementations simultaneously, as long as they conform to the interface
Test Isolation: Unit tests compile and run without real infrastructure, using mock implementations
Plugin Architecture: New implementations can be developed and tested completely independently, then "plugged in" at runtime

Wiring It Together: The Composition Root

When we invert dependencies, we face a practical question: if the business logic doesn't know about concrete implementations, how do they get connected at runtime? The answer is the Composition Root pattern.

The Composition Root

The Composition Root is a single place in your application where all the concrete implementations are instantiated and wired together. It's typically at the application's entry point — the main function, the app bootstrap, or the DI container configuration. This is the ONLY place that knows about all concrete types.

composition-root.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
// ═══════════════════════════════════════════════════════════════════
// 📦 main.ts (or bootstrap.ts, app.ts)
// The COMPOSITION ROOT — the only place that knows all concrete types
// ═══════════════════════════════════════════════════════════════════
 
import { Pool } from 'pg';
 
// Business Logic (abstractions)
import { OrderService } from './business-logic/order-service';
import { PaymentService } from './business-logic/payment-service';
 
// Infrastructure (concrete implementations)
import { PostgresOrderRepository } from './infrastructure/postgres/postgres-order-repository';
import { StripePaymentGateway } from './infrastructure/stripe/stripe-payment-gateway';
import { SesEmailNotifier } from './infrastructure/aws/ses-email-notifier';
 
// Presentation
import { OrderController } from './presentation/order-controller';
import { createApp } from './presentation/app';
 
async function main() {
    // ═══════════════════════════════════════════════════════════════
    // STEP 1: Create infrastructure dependencies
    // ═══════════════════════════════════════════════════════════════
    
    const pool = new Pool({ connectionString: process.env.DATABASE_URL });
    const stripeApiKey = process.env.STRIPE_API_KEY!;
    
    // ═══════════════════════════════════════════════════════════════
    // STEP 2: Create concrete implementations of abstractions
    // ═══════════════════════════════════════════════════════════════
    
    const orderRepository = new PostgresOrderRepository(pool);
    const paymentGateway = new StripePaymentGateway(stripeApiKey);
    const notifier = new SesEmailNotifier(process.env.AWS_REGION!);
    
    // ═══════════════════════════════════════════════════════════════
    // STEP 3: Wire implementations into business logic services
    // ═══════════════════════════════════════════════════════════════
    
    const orderService = new OrderService(orderRepository, notifier);
    const paymentService = new PaymentService(paymentGateway, orderRepository);
    
    // ═══════════════════════════════════════════════════════════════
    // STEP 4: Wire services into presentation layer
    // ═══════════════════════════════════════════════════════════════
    
    const orderController = new OrderController(orderService, paymentService);
    
    // ═══════════════════════════════════════════════════════════════
    // STEP 5: Start the application
    // ═══════════════════════════════════════════════════════════════
    
    const app = createApp(orderController);
    await app.listen(3000);
    console.log('Application started on port 3000');
}
 
// ═══════════════════════════════════════════════════════════════════
// ALTERNATIVE: Using a Dependency Injection Container
// ═══════════════════════════════════════════════════════════════════
 
import { Container } from 'inversify';
 
function configureContainer(): Container {
    const container = new Container();
    
    // Bind abstractions to concrete implementations
    container.bind<OrderRepository>('OrderRepository')
        .to(PostgresOrderRepository)
        .inSingletonScope();
    
    container.bind<PaymentGateway>('PaymentGateway')
        .to(StripePaymentGateway)
        .inSingletonScope();
    
    container.bind<CustomerNotifier>('CustomerNotifier')
        .to(SesEmailNotifier)
        .inSingletonScope();
    
    // Bind services (they'll automatically receive dependencies)
    container.bind<OrderService>(OrderService).toSelf();
    container.bind<PaymentService>(PaymentService).toSelf();
    
    return container;
}
 
// To switch from PostgreSQL to DynamoDB:
// container.bind<OrderRepository>('OrderRepository')
//     .to(DynamoOrderRepository)  // <-- Just change this line!
//     .inSingletonScope();

Key Properties of the Composition Root:

Single Location: All wiring happens in one place, making it easy to see the system's structure
At the Edge: It's at the outermost layer of the application, typically the entry point
High Knowledge: This is the ONLY place that knows about all concrete types
Easy Switching: To change implementations, modify only this one location
Environment Flexibility: Different configurations for dev/test/production can swap implementations

Summary: From Rigid to Flexible Architecture

We've conducted a thorough comparison of traditional versus inverted dependency structures. Let's consolidate the key insights:

Key Takeaways

•Traditional dependencies flow downward — high-level modules import from low-level modules, creating cascading change propagation.
•DIP inverts compile-time dependencies — low-level modules import interfaces from high-level modules, while runtime behavior remains unchanged.
•The interface must be owned by the consumer — this is what makes the inversion happen; implementations depend on consumer-defined abstractions.
•Inverted structures enable isolation — business logic compiles, tests, and deploys independently of infrastructure.
•Infrastructure becomes plugin-like — switching databases, payment providers, or any infrastructure is a configuration change, not surgery.
•The Composition Root connects everything — a single location where concrete implementations are wired to abstractions.

What's Next:

Now that we understand the mechanics of dependency inversion, we'll explore why it matters for real-world software. The next page examines the flexibility, maintainability, and testability benefits that DIP enables.

Page Complete

You can now draw and explain both traditional and inverted dependency structures. You understand how source code dependencies differ from runtime flow, and you know how the Composition Root pattern wires everything together. Next, we'll see why DIP is essential for building flexible, maintainable systems.