Isolating Concerns — Separation of Concerns | OneNoughtOne

0/86

System Design (HLD)Separation of Concerns

Separation of Concerns

LevelIntermediate

Duration75 mins

TopicSeparation of Concerns

2 / 4

Isolating Concerns

From Recognition to Separation

Identifying concerns is only the first step. The real engineering skill lies in isolating them—creating code structures where each concern lives in its own well-defined space, interacting with others through explicit, narrow interfaces. This isolation is what transforms a tangled codebase into a maintainable system. Isolation means that understanding concern A doesn't require understanding concerns B, C, and D. It means modifying concern A doesn't risk breaking concerns B, C, and D. It means testing concern A doesn't require setting up the entire world that concerns B, C, and D depend on. This page covers the techniques, patterns, and architectural approaches that make concern isolation practical in real systems.

What You Will Learn

By the end of this page, you will master the fundamental techniques for isolating concerns: encapsulation, abstraction, modular decomposition, layered architecture, and dependency management. You'll understand how these work together to create systems where each piece can evolve independently.

The Isolation Imperative

Why does isolation matter so much? Because software is fundamentally about managing change. Requirements evolve, technologies advance, bugs are discovered, performance must be tuned, and team members transition. The question isn't whether your code will change—it's whether those changes will be surgical or invasive. The Cost of Entanglement: When concerns are entangled, changes become exponentially difficult:

entangled-concerns.ts
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
// BEFORE: Concerns entangled in a single function
class OrderController {
    async handleCreateOrder(req: Request, res: Response) {
        // Logging concern
        console.log(`[INFO] Order request received at ${new Date()}`);
        
        // Validation concern
        if (!req.body.items || req.body.items.length === 0) {
            console.log(`[WARN] Empty order rejected`);
            return res.status(400).json({ error: 'No items' });
        }
        
        // Authentication concern
        const user = await db.users.findOne({ token: req.headers.authorization });
        if (!user) {
            console.log(`[WARN] Unauthorized access attempt`);
            return res.status(401).json({ error: 'Unauthorized' });
        }
        
        // Business logic concern
        let total = 0;
        for (const item of req.body.items) {
            const product = await db.products.findOne({ id: item.productId });
            total += product.price * item.quantity;
        }
        
        // Discount concern
        if (user.isPremium) total *= 0.9;
        if (total > 100) total *= 0.95;
        
        // Persistence concern
        const order = await db.orders.insert({
            userId: user.id,
            items: req.body.items,
            total,
            createdAt: new Date()
        });
        
        // Notification concern
        await emailService.send({
            to: user.email,
            subject: 'Order Confirmation',
            body: `Your order #${order.id} for $${total} has been placed.`
        });
        
        // Logging concern (again)
        console.log(`[INFO] Order ${order.id} created for user ${user.id}`);
        
        // Response concern
        return res.status(201).json({ order });
    }
}
 
// Problems:
// 1. To change logging format, you must edit this function
// 2. To change validation rules, you must edit this function
// 3. To change discount logic, you must edit this function
// 4. To test business logic, you need the entire HTTP context
// 5. Any change risks breaking something else
// 6. The function is nearly impossible to reason about holistically

The Isolation Benefit: When concerns are isolated, changes become localized and predictable:

isolated-concerns.ts
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
// AFTER: Concerns isolated into separate units
class OrderController {
    constructor(
        private orderService: OrderService,
        private authService: AuthService,
        private logger: Logger
    ) {}
    
    async handleCreateOrder(req: Request, res: Response) {
        // Controller only orchestrates - each concern lives elsewhere
        const user = await this.authService.authenticate(req);
        const orderRequest = OrderRequest.fromHttp(req.body);
        const order = await this.orderService.createOrder(orderRequest, user);
        
        this.logger.info('Order created', { orderId: order.id, userId: user.id });
        return res.status(201).json(OrderResponse.fromDomain(order));
    }
}
 
class OrderService {
    constructor(
        private validator: OrderValidator,
        private calculator: PriceCalculator,
        private repository: OrderRepository,
        private notifications: NotificationService
    ) {}
    
    async createOrder(request: OrderRequest, user: User): Promise<Order> {
        // Each step delegates to a specialist
        this.validator.validate(request);
        const total = this.calculator.calculateTotal(request.items, user);
        const order = await this.repository.save(request.toOrder(user.id, total));
        await this.notifications.orderCreated(order, user);
        return order;
    }
}
 
class PriceCalculator {
    constructor(private discountService: DiscountService) {}
    
    calculateTotal(items: OrderItem[], user: User): Money {
        const subtotal = items.reduce((sum, item) => sum.add(item.total()), Money.zero());
        return this.discountService.applyDiscounts(subtotal, user);
    }
}
 
// Benefits:
// 1. Change logging format? Edit only Logger
// 2. Change validation rules? Edit only OrderValidator
// 3. Change discount logic? Edit only DiscountService
// 4. Test business logic? No HTTP context needed
// 5. Each class has a single, clear purpose
// 6. Each class can be understood in isolation

The One-Change Principle

A well-isolated concern should require changes in exactly one place when it evolves. If changing your logging format requires edits across 50 files, logging is not isolated. If changing your discount calculation touches only the DiscountService, that concern is properly isolated.

Encapsulation as the Foundation of Isolation

Encapsulation is the most fundamental mechanism for isolating concerns. It means bundling related data and behavior together while hiding internal details behind a public interface. Other code interacts with the encapsulated unit only through its defined interface, never directly manipulating its internals. The Three Aspects of Encapsulation:

Encapsulation Dimensions

•Bundling — Related data and operations are grouped together (a class, a module, a namespace). The MoneyConverter class contains both currency rates and conversion logic.
•Information Hiding — Implementation details are concealed behind visibility modifiers (private, protected). External code cannot depend on internal structure.
•Interface Definition — The public surface area is explicit and intentional. Only what's meant to be used is accessible; everything else is hidden.

encapsulation-example.ts
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
// Poor encapsulation - internals exposed
class ShoppingCart {
    public items: CartItem[] = [];
    public discountPercentage: number = 0;
    public taxRate: number = 0.08;
    
    // Anyone can manipulate internals directly
}
 
// Usage - external code depends on internals
const cart = new ShoppingCart();
cart.items.push({ product: p1, quantity: 2 });
cart.discountPercentage = 0.1;
const subtotal = cart.items.reduce((s, i) => s + i.product.price * i.quantity, 0);
const total = subtotal * (1 - cart.discountPercentage) * (1 + cart.taxRate);
// Calculation logic is scattered throughout codebase
 
// ─────────────────────────────────────────────────────────────────
 
// Good encapsulation - internals hidden
class ShoppingCart {
    private items: CartItem[] = [];
    private appliedDiscounts: Discount[] = [];
    private readonly taxCalculator: TaxCalculator;
    
    constructor(taxCalculator: TaxCalculator) {
        this.taxCalculator = taxCalculator;
    }
    
    addItem(product: Product, quantity: number): void {
        const existing = this.items.find(i => i.product.id === product.id);
        if (existing) {
            existing.quantity += quantity;
        } else {
            this.items.push({ product, quantity });
        }
    }
    
    removeItem(productId: string): void {
        this.items = this.items.filter(i => i.product.id !== productId);
    }
    
    applyDiscount(discount: Discount): void {
        if (discount.isApplicableTo(this)) {
            this.appliedDiscounts.push(discount);
        }
    }
    
    getTotal(): Money {
        const subtotal = this.calculateSubtotal();
        const afterDiscounts = this.applyDiscountsToTotal(subtotal);
        return this.taxCalculator.addTax(afterDiscounts);
    }
    
    private calculateSubtotal(): Money {
        return this.items.reduce(
            (sum, item) => sum.add(item.product.price.multiply(item.quantity)),
            Money.zero()
        );
    }
    
    private applyDiscountsToTotal(amount: Money): Money {
        return this.appliedDiscounts.reduce(
            (total, discount) => discount.apply(total),
            amount
        );
    }
}
 
// Usage - external code uses interface only
const cart = new ShoppingCart(taxCalculator);
cart.addItem(product1, 2);
cart.applyDiscount(percentDiscount);
const total = cart.getTotal();
// Calculation logic is encapsulated

Getter/Setter Trap

Providing getters and setters for every field is not encapsulation—it's syntactic overhead that still exposes internals. True encapsulation asks: 'What operations does this concern need to expose?' not 'How can I access all the data?'

Abstraction for Concern Decoupling

While encapsulation bundles a concern's internals, abstraction defines how concerns communicate without knowing each other's implementations. Abstractions are contracts—interfaces, protocols, or type definitions—that specify what a concern does without specifying how it does it. The Power of Abstraction: When concern A depends on an abstraction rather than a concrete implementation of concern B, you can: Replace the implementation of B without changing A Test A with a mock/stub implementation of B Evolve B's internals without affecting A Compose multiple implementations of B for different contexts

abstraction-example.ts
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
// Without abstraction: direct coupling
class OrderService {
    private stripeClient = new StripePaymentClient();
    
    async processOrder(order: Order): Promise<void> {
        // Directly coupled to Stripe implementation
        await this.stripeClient.createCharge({
            amount: order.total.cents,
            currency: 'usd',
            source: order.paymentToken
        });
    }
}
// Problem: Changing payment provider requires rewriting OrderService
 
// ─────────────────────────────────────────────────────────────────
 
// With abstraction: decoupled via interface
interface PaymentProcessor {
    processPayment(amount: Money, token: PaymentToken): Promise<PaymentResult>;
}
 
class StripePaymentProcessor implements PaymentProcessor {
    async processPayment(amount: Money, token: PaymentToken): Promise<PaymentResult> {
        // Stripe-specific implementation
        const charge = await stripe.charges.create({
            amount: amount.toCents(),
            currency: amount.currency.code,
            source: token.value
        });
        return { transactionId: charge.id, success: true };
    }
}
 
class SquarePaymentProcessor implements PaymentProcessor {
    async processPayment(amount: Money, token: PaymentToken): Promise<PaymentResult> {
        // Square-specific implementation
        const payment = await squareClient.payments.create({
            sourceId: token.value,
            amountMoney: { amount: amount.toCents(), currency: amount.currency.code }
        });
        return { transactionId: payment.id, success: true };
    }
}
 
class OrderService {
    constructor(private paymentProcessor: PaymentProcessor) {}
    
    async processOrder(order: Order): Promise<void> {
        // Decoupled from any specific payment provider
        await this.paymentProcessor.processPayment(order.total, order.paymentToken);
    }
}
 
// Usage in production
const orderService = new OrderService(new StripePaymentProcessor());
 
// Usage in tests - no actual payments
const orderService = new OrderService(new MockPaymentProcessor());
 
// Switching providers - no OrderService changes
const orderService = new OrderService(new SquarePaymentProcessor());

Designing Effective Abstractions: Not all abstractions are equally valuable. The best abstractions are: Stable — They change less frequently than their implementations Minimal — They expose only what clients actually need Focused — They represent a single, coherent concern Implementation-agnostic — They don't leak details of any particular implementation

Poor Abstraction Design

•Interface with 20+ methods
•Method signatures tied to specific databases
•Exposing SQL query strings
•'Repository' that also handles caching and logging
•Abstraction that only one implementation will ever use

Good Abstraction Design

•Interface with 3-5 focused methods
•Domain-oriented method signatures
•Data structures independent of storage
•'Repository' for persistence only; caching/logging separate
•Abstraction anticipating multiple implementations

The Substitution Test

A well-designed abstraction passes the 'substitution test': can you imagine at least two meaningfully different implementations? If not, the abstraction may be premature or poorly conceived. Good abstractions admit variety—real implementations, test doubles, adapters, decorators.

Modular Decomposition

Beyond individual classes, concerns can be isolated at the module level—grouping related classes, functions, and types into cohesive packages that represent complete capability areas. Modular decomposition creates larger-scale boundaries that help manage complexity in substantial systems. What Makes a Good Module: A module should be a coherent grouping that represents a single area of concern, with explicit dependencies on other modules and a well-defined public API.

module-structure.ts
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
// Project structure demonstrating modular decomposition
//
// src/
// ├── modules/
// │   ├── authentication/        # Authentication concern
// │   │   ├── index.ts          # Public API
// │   │   ├── auth.service.ts
// │   │   ├── jwt.provider.ts
// │   │   ├── auth.middleware.ts
// │   │   └── auth.types.ts
// │   │
// │   ├── ordering/              # Order management concern
// │   │   ├── index.ts          # Public API
// │   │   ├── order.service.ts
// │   │   ├── order.repository.ts
// │   │   ├── order.validator.ts
// │   │   └── order.types.ts
// │   │
// │   ├── payments/              # Payment processing concern
// │   │   ├── index.ts          # Public API
// │   │   ├── payment.service.ts
// │   │   ├── stripe.adapter.ts
// │   │   ├── payment.repository.ts
// │   │   └── payment.types.ts
// │   │
// │   └── notifications/         # Notification concern
// │       ├── index.ts          # Public API
// │       ├── notification.service.ts
// │       ├── email.sender.ts
// │       ├── sms.sender.ts
// │       └── notification.types.ts
 
// authentication/index.ts - explicit public API
export { AuthService } from './auth.service';
export { authMiddleware } from './auth.middleware';
export type { User, AuthToken, Credentials } from './auth.types';
// Internal implementation details are NOT exported
 
// ordering/order.service.ts - uses other modules via their public APIs
import { AuthService } from '../authentication';
import { PaymentService } from '../payments';
import { NotificationService } from '../notifications';
 
export class OrderService {
    constructor(
        private auth: AuthService,
        private payments: PaymentService,
        private notifications: NotificationService,
        private repository: OrderRepository
    ) {}
    
    async createOrder(request: CreateOrderRequest, token: AuthToken): Promise<Order> {
        const user = await this.auth.validateToken(token);
        const order = await this.repository.save(request.toOrder(user.id));
        await this.payments.processPayment(order.total, request.paymentToken);
        await this.notifications.orderCreated(order, user);
        return order;
    }
}

Module Design Principles

•High Internal Cohesion — Everything within the module relates to the same concern. The payments module contains only payment-related code.
•Low External Coupling — Dependencies between modules are minimized and explicit. Modules communicate through defined interfaces.
•Clear Public API — Each module exposes a limited, intentional surface. Internal implementation is hidden.
•Single Responsibility — Each module addresses one concern. Need both payments and notifications? That's two modules.
•Independent Deployability (when applicable) — In microservice architectures, modules may become independent deployable units.

Module Boundaries and Teams

Module boundaries often align with team boundaries (Conway's Law in action). A payments module might be owned by the payments team. This alignment means that most changes to a concern affect only that team, reducing coordination overhead and enabling parallel development.

Layered Architecture for Concern Separation

One of the most powerful and widely-used patterns for concern isolation is layered architecture . This architectural style organizes a system into horizontal layers, each representing a distinct level of abstraction. Layers communicate only with adjacent layers, creating a clean separation between technical concerns and business logic. The Classic Layered Architecture:

Traditional Layered Architecture
Layer	Responsibility	Examples	Dependencies
Presentation	User interface and input handling	Controllers, views, API endpoints, serializers	→ Application
Application	Use case orchestration, transaction boundaries	Application services, DTOs, use case handlers	→ Domain
Domain	Core business logic and rules	Entities, value objects, domain services, repositories (interfaces)	→ (Pure, no dependencies)
Infrastructure	Technical capabilities and external systems	Repository implementations, API clients, queue adapters	→ Domain (implements interfaces)

layered-architecture.ts
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
// PRESENTATION LAYER
// Concern: HTTP handling, request/response formatting
@Controller('/orders')
class OrderController {
    constructor(private orderAppService: OrderApplicationService) {}
    
    @Post('/')
    async createOrder(@Body() dto: CreateOrderDto, @CurrentUser() user: User) {
        // Maps HTTP to application layer
        const command = CreateOrderCommand.fromDto(dto, user.id);
        const result = await this.orderAppService.createOrder(command);
        return OrderResponseDto.fromDomain(result);
    }
}
 
// APPLICATION LAYER
// Concern: Use case orchestration, transaction boundaries
class OrderApplicationService {
    constructor(
        private orderDomainService: OrderDomainService,
        private orderRepository: OrderRepository,
        private unitOfWork: UnitOfWork
    ) {}
    
    @Transactional()
    async createOrder(command: CreateOrderCommand): Promise<Order> {
        // Orchestrates the use case without business logic
        const order = this.orderDomainService.createOrder(command);
        await this.orderRepository.save(order);
        return order;
    }
}
 
// DOMAIN LAYER
// Concern: Pure business logic, no infrastructure dependencies
class OrderDomainService {
    constructor(
        private pricingPolicy: PricingPolicy,
        private inventoryPolicy: InventoryPolicy
    ) {}
    
    createOrder(command: CreateOrderCommand): Order {
        // Pure business logic
        const lineItems = command.items.map(item => 
            LineItem.create(item.productId, item.quantity)
        );
        
        this.inventoryPolicy.validateAvailability(lineItems);
        const total = this.pricingPolicy.calculateTotal(lineItems, command.userId);
        
        return Order.create(command.userId, lineItems, total);
    }
}
 
class Order {
    private constructor(
        private id: OrderId,
        private userId: UserId,
        private lineItems: LineItem[],
        private total: Money,
        private status: OrderStatus
    ) {}
    
    static create(userId: UserId, items: LineItem[], total: Money): Order {
        // Business rules encapsulated
        if (items.length === 0) {
            throw new DomainError('Order must have at least one item');
        }
        return new Order(OrderId.generate(), userId, items, total, OrderStatus.Pending);
    }
}
 
// INFRASTRUCTURE LAYER
// Concern: Technical implementation of domain interfaces
class PostgresOrderRepository implements OrderRepository {
    constructor(private db: Database) {}
    
    async save(order: Order): Promise<void> {
        // Technical details of persistence
        await this.db.query(
            'INSERT INTO orders (id, user_id, total, status) VALUES ($1, $2, $3, $4)',
            [order.id.value, order.userId.value, order.total.cents, order.status]
        );
    }
}

The Dependency Rule: In well-structured layered architectures, dependencies flow in one direction: from outer layers toward inner layers. The domain layer depends on nothing; infrastructure depends on domain interfaces. This inversion ensures that business logic is never polluted by technical concerns.

Clean Architecture / Hexagonal Architecture

Layered architecture variants like Clean Architecture (Robert C. Martin) and Hexagonal Architecture (Alistair Cockburn) emphasize dependency inversion even more strongly. The core principle remains: isolate business logic from delivery mechanisms (web, CLI, etc.) and infrastructure (databases, queues, etc.).

Composition Over Inheritance

Inheritance is often taught as the primary mechanism for code reuse in object-oriented programming. However, for concern isolation, composition is almost always superior. Inheritance creates tight coupling between parent and child; composition creates loose coupling between components. The Problem with Inheritance: Inheritance couples concerns in subtle, problematic ways:

inheritance-problems.ts
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
// Concern coupling through inheritance
abstract class BaseService {
    protected logger: Logger;
    protected metrics: Metrics;
    protected cache: Cache;
    
    constructor(container: ServiceContainer) {
        this.logger = container.get(Logger);
        this.metrics = container.get(Metrics);
        this.cache = container.get(Cache);
    }
    
    protected log(message: string): void {
        this.logger.info(message);
    }
    
    protected recordMetric(name: string, value: number): void {
        this.metrics.record(name, value);
    }
    
    protected cached<T>(key: string, fn: () => T): T {
        return this.cache.getOrSet(key, fn);
    }
}
 
class OrderService extends BaseService {
    private orderRepository: OrderRepository;
    
    constructor(container: ServiceContainer) {
        super(container); // Must call parent constructor
        this.orderRepository = container.get(OrderRepository);
    }
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        this.log('Creating order'); // Uses inherited method
        const start = Date.now();
        
        const order = await this.orderRepository.save(request.toOrder());
        
        this.recordMetric('order.created', Date.now() - start);
        return order;
    }
}
 
// Problems:
// 1. OrderService is coupled to BaseService's dependencies (logging, metrics, caching)
// 2. Adding a concern to BaseService affects ALL subclasses
// 3. Cannot have an OrderService without logging capability
// 4. Hard to test OrderService without the entire hierarchy
// 5. 'Is-a' relationship (OrderService IS-A BaseService) doesn't make semantic sense

Composition as the Solution: Composition injects concerns as dependencies rather than embedding them through inheritance:

composition-solution.ts
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
// Concerns composed, not inherited
class OrderService {
    constructor(
        private orderRepository: OrderRepository,
        private logger: Logger,           // Concern injected
        private metrics: MetricsRecorder, // Concern injected
        private cache: Cache              // Concern injected
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        this.logger.info('Creating order');
        const start = Date.now();
        
        const order = await this.orderRepository.save(request.toOrder());
        
        this.metrics.record('order.created', Date.now() - start);
        return order;
    }
}
 
// Benefits:
// 1. OrderService explicitly declares its dependencies
// 2. Each concern can be tested/replaced independently
// 3. Can create OrderService with different logging implementations
// 4. Adding concerns doesn't affect other services
// 5. Relationships make semantic sense (OrderService HAS-A Logger)
 
// Even better - use decorators for cross-cutting concerns
class OrderService {
    constructor(private orderRepository: OrderRepository) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        // Pure business logic only
        return this.orderRepository.save(request.toOrder());
    }
}
 
// Apply concerns via decoration
const orderService = new OrderService(orderRepository);
const loggedService = new LoggingDecorator(orderService);
const meteredService = new MetricsDecorator(loggedService);
const cachedService = new CachingDecorator(meteredService);
 
// Or use middleware pattern
const orderService = pipe(
    new OrderService(orderRepository),
    withLogging(logger),
    withMetrics(metrics),
    withCaching(cache)
);

When Inheritance Works

Inheritance isn't always wrong. It works well when there's a genuine 'is-a' relationship and when the hierarchy represents variations within a single concern. A PostgresRepository IS-A Repository. A DiscountedPrice IS-A Price. But a UserService IS-NOT-A LoggingBaseService.

Dependency Injection for Concern Assembly

Dependency Injection (DI) is the mechanism that makes concern isolation practical at scale. Rather than having components create or locate their dependencies, dependencies are provided ('injected') from outside. This pattern enables all the benefits of abstraction and composition we've discussed. The Three Types of Dependency Injection:

Dependency Injection Types
Type	Mechanism	When to Use	Example
Constructor Injection	Dependencies passed via constructor	Required dependencies that shouldn't change	constructor(private repo: Repository)
Method Injection	Dependencies passed per method call	Dependencies that vary per operation	execute(command, context: ExecutionContext)
Property Injection	Dependencies set after construction	Optional dependencies with defaults	@Inject() logger?: Logger

dependency-injection.ts
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
// WITHOUT DI: Hard-coded dependencies
class OrderService {
    private repository = new PostgresOrderRepository();
    private emailer = new SmtpEmailService();
    private validator = new OrderValidator();
    
    // Problems:
    // - Can't use different implementations
    // - Can't test without real database/email
    // - Can't configure dependencies
}
 
// ─────────────────────────────────────────────────────────────────
 
// WITH DI: Dependencies injected
interface OrderRepository {
    save(order: Order): Promise<void>;
    findById(id: string): Promise<Order>;
}
 
interface EmailService {
    send(email: Email): Promise<void>;
}
 
interface OrderValidator {
    validate(request: CreateOrderRequest): ValidationResult;
}
 
class OrderService {
    constructor(
        private repository: OrderRepository,  // Interface, not implementation
        private emailer: EmailService,
        private validator: OrderValidator
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        const validation = this.validator.validate(request);
        if (!validation.isValid) {
            throw new ValidationError(validation.errors);
        }
        
        const order = Order.create(request);
        await this.repository.save(order);
        await this.emailer.send(OrderConfirmationEmail.for(order));
        return order;
    }
}
 
// Production composition
const orderService = new OrderService(
    new PostgresOrderRepository(database),
    new SmtpEmailService(smtpConfig),
    new DefaultOrderValidator()
);
 
// Test composition - no external dependencies
const testService = new OrderService(
    new InMemoryOrderRepository(),
    new MockEmailService(),
    new TestOrderValidator()
);
 
// Alternative production composition
const orderService = new OrderService(
    new MongoOrderRepository(mongoClient),  // Different database
    new SendGridEmailService(apiKey),       // Different email provider
    new StrictOrderValidator()              // Stricter validation
);

DI Containers: For large applications, manually wiring dependencies becomes tedious. DI containers (also called IoC containers) automate this process by managing object creation and lifecycle:

di-container.ts
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
// Using a DI container (example with typical patterns)
import { Container, Injectable, Inject } from 'di-container';
 
@Injectable()
class PostgresOrderRepository implements OrderRepository {
    constructor(@Inject('DATABASE') private db: Database) {}
    // ...
}
 
@Injectable()
class SmtpEmailService implements EmailService {
    constructor(@Inject('SMTP_CONFIG') private config: SmtpConfig) {}
    // ...
}
 
@Injectable()
class OrderService {
    constructor(
        private repository: OrderRepository,
        private emailer: EmailService,
        private validator: OrderValidator
    ) {}
    // ...
}
 
// Container configuration
const container = new Container();
container.bind('DATABASE').toValue(postgresConnection);
container.bind('SMTP_CONFIG').toValue(smtpConfig);
container.bind(OrderRepository).to(PostgresOrderRepository);
container.bind(EmailService).to(SmtpEmailService);
container.bind(OrderValidator).to(DefaultOrderValidator);
container.bind(OrderService).toSelf();
 
// Resolution - container handles wiring
const orderService = container.get(OrderService);
// All dependencies automatically resolved

The DI Mindset

DI is a mindset more than a technology. The key insight is: a class should not know HOW to obtain its dependencies, only WHAT it needs. When you write 'new SomeService()' inside a class, you've hardcoded a dependency. When you receive it via constructor, you've declared a requirement that others fulfill.

System Design (HLD)Separation of Concerns

Separation of Concerns

LevelIntermediate

Duration75 mins

TopicSeparation of Concerns

2 / 4

Isolating Concerns

From Recognition to Separation

Identifying concerns is only the first step. The real engineering skill lies in isolating them—creating code structures where each concern lives in its own well-defined space, interacting with others through explicit, narrow interfaces. This isolation is what transforms a tangled codebase into a maintainable system. Isolation means that understanding concern A doesn't require understanding concerns B, C, and D. It means modifying concern A doesn't risk breaking concerns B, C, and D. It means testing concern A doesn't require setting up the entire world that concerns B, C, and D depend on. This page covers the techniques, patterns, and architectural approaches that make concern isolation practical in real systems.

What You Will Learn

By the end of this page, you will master the fundamental techniques for isolating concerns: encapsulation, abstraction, modular decomposition, layered architecture, and dependency management. You'll understand how these work together to create systems where each piece can evolve independently.

The Isolation Imperative

Why does isolation matter so much? Because software is fundamentally about managing change. Requirements evolve, technologies advance, bugs are discovered, performance must be tuned, and team members transition. The question isn't whether your code will change—it's whether those changes will be surgical or invasive. The Cost of Entanglement: When concerns are entangled, changes become exponentially difficult:

entangled-concerns.ts
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
// BEFORE: Concerns entangled in a single function
class OrderController {
    async handleCreateOrder(req: Request, res: Response) {
        // Logging concern
        console.log(`[INFO] Order request received at ${new Date()}`);
        
        // Validation concern
        if (!req.body.items || req.body.items.length === 0) {
            console.log(`[WARN] Empty order rejected`);
            return res.status(400).json({ error: 'No items' });
        }
        
        // Authentication concern
        const user = await db.users.findOne({ token: req.headers.authorization });
        if (!user) {
            console.log(`[WARN] Unauthorized access attempt`);
            return res.status(401).json({ error: 'Unauthorized' });
        }
        
        // Business logic concern
        let total = 0;
        for (const item of req.body.items) {
            const product = await db.products.findOne({ id: item.productId });
            total += product.price * item.quantity;
        }
        
        // Discount concern
        if (user.isPremium) total *= 0.9;
        if (total > 100) total *= 0.95;
        
        // Persistence concern
        const order = await db.orders.insert({
            userId: user.id,
            items: req.body.items,
            total,
            createdAt: new Date()
        });
        
        // Notification concern
        await emailService.send({
            to: user.email,
            subject: 'Order Confirmation',
            body: `Your order #${order.id} for $${total} has been placed.`
        });
        
        // Logging concern (again)
        console.log(`[INFO] Order ${order.id} created for user ${user.id}`);
        
        // Response concern
        return res.status(201).json({ order });
    }
}
 
// Problems:
// 1. To change logging format, you must edit this function
// 2. To change validation rules, you must edit this function
// 3. To change discount logic, you must edit this function
// 4. To test business logic, you need the entire HTTP context
// 5. Any change risks breaking something else
// 6. The function is nearly impossible to reason about holistically

The Isolation Benefit: When concerns are isolated, changes become localized and predictable:

isolated-concerns.ts
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
// AFTER: Concerns isolated into separate units
class OrderController {
    constructor(
        private orderService: OrderService,
        private authService: AuthService,
        private logger: Logger
    ) {}
    
    async handleCreateOrder(req: Request, res: Response) {
        // Controller only orchestrates - each concern lives elsewhere
        const user = await this.authService.authenticate(req);
        const orderRequest = OrderRequest.fromHttp(req.body);
        const order = await this.orderService.createOrder(orderRequest, user);
        
        this.logger.info('Order created', { orderId: order.id, userId: user.id });
        return res.status(201).json(OrderResponse.fromDomain(order));
    }
}
 
class OrderService {
    constructor(
        private validator: OrderValidator,
        private calculator: PriceCalculator,
        private repository: OrderRepository,
        private notifications: NotificationService
    ) {}
    
    async createOrder(request: OrderRequest, user: User): Promise<Order> {
        // Each step delegates to a specialist
        this.validator.validate(request);
        const total = this.calculator.calculateTotal(request.items, user);
        const order = await this.repository.save(request.toOrder(user.id, total));
        await this.notifications.orderCreated(order, user);
        return order;
    }
}
 
class PriceCalculator {
    constructor(private discountService: DiscountService) {}
    
    calculateTotal(items: OrderItem[], user: User): Money {
        const subtotal = items.reduce((sum, item) => sum.add(item.total()), Money.zero());
        return this.discountService.applyDiscounts(subtotal, user);
    }
}
 
// Benefits:
// 1. Change logging format? Edit only Logger
// 2. Change validation rules? Edit only OrderValidator
// 3. Change discount logic? Edit only DiscountService
// 4. Test business logic? No HTTP context needed
// 5. Each class has a single, clear purpose
// 6. Each class can be understood in isolation

The One-Change Principle

A well-isolated concern should require changes in exactly one place when it evolves. If changing your logging format requires edits across 50 files, logging is not isolated. If changing your discount calculation touches only the DiscountService, that concern is properly isolated.

Encapsulation as the Foundation of Isolation

Encapsulation is the most fundamental mechanism for isolating concerns. It means bundling related data and behavior together while hiding internal details behind a public interface. Other code interacts with the encapsulated unit only through its defined interface, never directly manipulating its internals. The Three Aspects of Encapsulation:

Encapsulation Dimensions

•Bundling — Related data and operations are grouped together (a class, a module, a namespace). The MoneyConverter class contains both currency rates and conversion logic.
•Information Hiding — Implementation details are concealed behind visibility modifiers (private, protected). External code cannot depend on internal structure.
•Interface Definition — The public surface area is explicit and intentional. Only what's meant to be used is accessible; everything else is hidden.

encapsulation-example.ts
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
// Poor encapsulation - internals exposed
class ShoppingCart {
    public items: CartItem[] = [];
    public discountPercentage: number = 0;
    public taxRate: number = 0.08;
    
    // Anyone can manipulate internals directly
}
 
// Usage - external code depends on internals
const cart = new ShoppingCart();
cart.items.push({ product: p1, quantity: 2 });
cart.discountPercentage = 0.1;
const subtotal = cart.items.reduce((s, i) => s + i.product.price * i.quantity, 0);
const total = subtotal * (1 - cart.discountPercentage) * (1 + cart.taxRate);
// Calculation logic is scattered throughout codebase
 
// ─────────────────────────────────────────────────────────────────
 
// Good encapsulation - internals hidden
class ShoppingCart {
    private items: CartItem[] = [];
    private appliedDiscounts: Discount[] = [];
    private readonly taxCalculator: TaxCalculator;
    
    constructor(taxCalculator: TaxCalculator) {
        this.taxCalculator = taxCalculator;
    }
    
    addItem(product: Product, quantity: number): void {
        const existing = this.items.find(i => i.product.id === product.id);
        if (existing) {
            existing.quantity += quantity;
        } else {
            this.items.push({ product, quantity });
        }
    }
    
    removeItem(productId: string): void {
        this.items = this.items.filter(i => i.product.id !== productId);
    }
    
    applyDiscount(discount: Discount): void {
        if (discount.isApplicableTo(this)) {
            this.appliedDiscounts.push(discount);
        }
    }
    
    getTotal(): Money {
        const subtotal = this.calculateSubtotal();
        const afterDiscounts = this.applyDiscountsToTotal(subtotal);
        return this.taxCalculator.addTax(afterDiscounts);
    }
    
    private calculateSubtotal(): Money {
        return this.items.reduce(
            (sum, item) => sum.add(item.product.price.multiply(item.quantity)),
            Money.zero()
        );
    }
    
    private applyDiscountsToTotal(amount: Money): Money {
        return this.appliedDiscounts.reduce(
            (total, discount) => discount.apply(total),
            amount
        );
    }
}
 
// Usage - external code uses interface only
const cart = new ShoppingCart(taxCalculator);
cart.addItem(product1, 2);
cart.applyDiscount(percentDiscount);
const total = cart.getTotal();
// Calculation logic is encapsulated

Getter/Setter Trap

Providing getters and setters for every field is not encapsulation—it's syntactic overhead that still exposes internals. True encapsulation asks: 'What operations does this concern need to expose?' not 'How can I access all the data?'

Abstraction for Concern Decoupling

While encapsulation bundles a concern's internals, abstraction defines how concerns communicate without knowing each other's implementations. Abstractions are contracts—interfaces, protocols, or type definitions—that specify what a concern does without specifying how it does it. The Power of Abstraction: When concern A depends on an abstraction rather than a concrete implementation of concern B, you can: Replace the implementation of B without changing A Test A with a mock/stub implementation of B Evolve B's internals without affecting A Compose multiple implementations of B for different contexts

abstraction-example.ts
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
// Without abstraction: direct coupling
class OrderService {
    private stripeClient = new StripePaymentClient();
    
    async processOrder(order: Order): Promise<void> {
        // Directly coupled to Stripe implementation
        await this.stripeClient.createCharge({
            amount: order.total.cents,
            currency: 'usd',
            source: order.paymentToken
        });
    }
}
// Problem: Changing payment provider requires rewriting OrderService
 
// ─────────────────────────────────────────────────────────────────
 
// With abstraction: decoupled via interface
interface PaymentProcessor {
    processPayment(amount: Money, token: PaymentToken): Promise<PaymentResult>;
}
 
class StripePaymentProcessor implements PaymentProcessor {
    async processPayment(amount: Money, token: PaymentToken): Promise<PaymentResult> {
        // Stripe-specific implementation
        const charge = await stripe.charges.create({
            amount: amount.toCents(),
            currency: amount.currency.code,
            source: token.value
        });
        return { transactionId: charge.id, success: true };
    }
}
 
class SquarePaymentProcessor implements PaymentProcessor {
    async processPayment(amount: Money, token: PaymentToken): Promise<PaymentResult> {
        // Square-specific implementation
        const payment = await squareClient.payments.create({
            sourceId: token.value,
            amountMoney: { amount: amount.toCents(), currency: amount.currency.code }
        });
        return { transactionId: payment.id, success: true };
    }
}
 
class OrderService {
    constructor(private paymentProcessor: PaymentProcessor) {}
    
    async processOrder(order: Order): Promise<void> {
        // Decoupled from any specific payment provider
        await this.paymentProcessor.processPayment(order.total, order.paymentToken);
    }
}
 
// Usage in production
const orderService = new OrderService(new StripePaymentProcessor());
 
// Usage in tests - no actual payments
const orderService = new OrderService(new MockPaymentProcessor());
 
// Switching providers - no OrderService changes
const orderService = new OrderService(new SquarePaymentProcessor());

Designing Effective Abstractions: Not all abstractions are equally valuable. The best abstractions are: Stable — They change less frequently than their implementations Minimal — They expose only what clients actually need Focused — They represent a single, coherent concern Implementation-agnostic — They don't leak details of any particular implementation

Poor Abstraction Design

•Interface with 20+ methods
•Method signatures tied to specific databases
•Exposing SQL query strings
•'Repository' that also handles caching and logging
•Abstraction that only one implementation will ever use

Good Abstraction Design

•Interface with 3-5 focused methods
•Domain-oriented method signatures
•Data structures independent of storage
•'Repository' for persistence only; caching/logging separate
•Abstraction anticipating multiple implementations

The Substitution Test

A well-designed abstraction passes the 'substitution test': can you imagine at least two meaningfully different implementations? If not, the abstraction may be premature or poorly conceived. Good abstractions admit variety—real implementations, test doubles, adapters, decorators.

Modular Decomposition

Beyond individual classes, concerns can be isolated at the module level—grouping related classes, functions, and types into cohesive packages that represent complete capability areas. Modular decomposition creates larger-scale boundaries that help manage complexity in substantial systems. What Makes a Good Module: A module should be a coherent grouping that represents a single area of concern, with explicit dependencies on other modules and a well-defined public API.

module-structure.ts
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
// Project structure demonstrating modular decomposition
//
// src/
// ├── modules/
// │   ├── authentication/        # Authentication concern
// │   │   ├── index.ts          # Public API
// │   │   ├── auth.service.ts
// │   │   ├── jwt.provider.ts
// │   │   ├── auth.middleware.ts
// │   │   └── auth.types.ts
// │   │
// │   ├── ordering/              # Order management concern
// │   │   ├── index.ts          # Public API
// │   │   ├── order.service.ts
// │   │   ├── order.repository.ts
// │   │   ├── order.validator.ts
// │   │   └── order.types.ts
// │   │
// │   ├── payments/              # Payment processing concern
// │   │   ├── index.ts          # Public API
// │   │   ├── payment.service.ts
// │   │   ├── stripe.adapter.ts
// │   │   ├── payment.repository.ts
// │   │   └── payment.types.ts
// │   │
// │   └── notifications/         # Notification concern
// │       ├── index.ts          # Public API
// │       ├── notification.service.ts
// │       ├── email.sender.ts
// │       ├── sms.sender.ts
// │       └── notification.types.ts
 
// authentication/index.ts - explicit public API
export { AuthService } from './auth.service';
export { authMiddleware } from './auth.middleware';
export type { User, AuthToken, Credentials } from './auth.types';
// Internal implementation details are NOT exported
 
// ordering/order.service.ts - uses other modules via their public APIs
import { AuthService } from '../authentication';
import { PaymentService } from '../payments';
import { NotificationService } from '../notifications';
 
export class OrderService {
    constructor(
        private auth: AuthService,
        private payments: PaymentService,
        private notifications: NotificationService,
        private repository: OrderRepository
    ) {}
    
    async createOrder(request: CreateOrderRequest, token: AuthToken): Promise<Order> {
        const user = await this.auth.validateToken(token);
        const order = await this.repository.save(request.toOrder(user.id));
        await this.payments.processPayment(order.total, request.paymentToken);
        await this.notifications.orderCreated(order, user);
        return order;
    }
}

Module Design Principles

•High Internal Cohesion — Everything within the module relates to the same concern. The payments module contains only payment-related code.
•Low External Coupling — Dependencies between modules are minimized and explicit. Modules communicate through defined interfaces.
•Clear Public API — Each module exposes a limited, intentional surface. Internal implementation is hidden.
•Single Responsibility — Each module addresses one concern. Need both payments and notifications? That's two modules.
•Independent Deployability (when applicable) — In microservice architectures, modules may become independent deployable units.

Module Boundaries and Teams

Module boundaries often align with team boundaries (Conway's Law in action). A payments module might be owned by the payments team. This alignment means that most changes to a concern affect only that team, reducing coordination overhead and enabling parallel development.

Layered Architecture for Concern Separation

One of the most powerful and widely-used patterns for concern isolation is layered architecture . This architectural style organizes a system into horizontal layers, each representing a distinct level of abstraction. Layers communicate only with adjacent layers, creating a clean separation between technical concerns and business logic. The Classic Layered Architecture:

Traditional Layered Architecture
Layer	Responsibility	Examples	Dependencies
Presentation	User interface and input handling	Controllers, views, API endpoints, serializers	→ Application
Application	Use case orchestration, transaction boundaries	Application services, DTOs, use case handlers	→ Domain
Domain	Core business logic and rules	Entities, value objects, domain services, repositories (interfaces)	→ (Pure, no dependencies)
Infrastructure	Technical capabilities and external systems	Repository implementations, API clients, queue adapters	→ Domain (implements interfaces)

layered-architecture.ts
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
// PRESENTATION LAYER
// Concern: HTTP handling, request/response formatting
@Controller('/orders')
class OrderController {
    constructor(private orderAppService: OrderApplicationService) {}
    
    @Post('/')
    async createOrder(@Body() dto: CreateOrderDto, @CurrentUser() user: User) {
        // Maps HTTP to application layer
        const command = CreateOrderCommand.fromDto(dto, user.id);
        const result = await this.orderAppService.createOrder(command);
        return OrderResponseDto.fromDomain(result);
    }
}
 
// APPLICATION LAYER
// Concern: Use case orchestration, transaction boundaries
class OrderApplicationService {
    constructor(
        private orderDomainService: OrderDomainService,
        private orderRepository: OrderRepository,
        private unitOfWork: UnitOfWork
    ) {}
    
    @Transactional()
    async createOrder(command: CreateOrderCommand): Promise<Order> {
        // Orchestrates the use case without business logic
        const order = this.orderDomainService.createOrder(command);
        await this.orderRepository.save(order);
        return order;
    }
}
 
// DOMAIN LAYER
// Concern: Pure business logic, no infrastructure dependencies
class OrderDomainService {
    constructor(
        private pricingPolicy: PricingPolicy,
        private inventoryPolicy: InventoryPolicy
    ) {}
    
    createOrder(command: CreateOrderCommand): Order {
        // Pure business logic
        const lineItems = command.items.map(item => 
            LineItem.create(item.productId, item.quantity)
        );
        
        this.inventoryPolicy.validateAvailability(lineItems);
        const total = this.pricingPolicy.calculateTotal(lineItems, command.userId);
        
        return Order.create(command.userId, lineItems, total);
    }
}
 
class Order {
    private constructor(
        private id: OrderId,
        private userId: UserId,
        private lineItems: LineItem[],
        private total: Money,
        private status: OrderStatus
    ) {}
    
    static create(userId: UserId, items: LineItem[], total: Money): Order {
        // Business rules encapsulated
        if (items.length === 0) {
            throw new DomainError('Order must have at least one item');
        }
        return new Order(OrderId.generate(), userId, items, total, OrderStatus.Pending);
    }
}
 
// INFRASTRUCTURE LAYER
// Concern: Technical implementation of domain interfaces
class PostgresOrderRepository implements OrderRepository {
    constructor(private db: Database) {}
    
    async save(order: Order): Promise<void> {
        // Technical details of persistence
        await this.db.query(
            'INSERT INTO orders (id, user_id, total, status) VALUES ($1, $2, $3, $4)',
            [order.id.value, order.userId.value, order.total.cents, order.status]
        );
    }
}

The Dependency Rule: In well-structured layered architectures, dependencies flow in one direction: from outer layers toward inner layers. The domain layer depends on nothing; infrastructure depends on domain interfaces. This inversion ensures that business logic is never polluted by technical concerns.

Clean Architecture / Hexagonal Architecture

Layered architecture variants like Clean Architecture (Robert C. Martin) and Hexagonal Architecture (Alistair Cockburn) emphasize dependency inversion even more strongly. The core principle remains: isolate business logic from delivery mechanisms (web, CLI, etc.) and infrastructure (databases, queues, etc.).

Composition Over Inheritance

Inheritance is often taught as the primary mechanism for code reuse in object-oriented programming. However, for concern isolation, composition is almost always superior. Inheritance creates tight coupling between parent and child; composition creates loose coupling between components. The Problem with Inheritance: Inheritance couples concerns in subtle, problematic ways:

inheritance-problems.ts
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
// Concern coupling through inheritance
abstract class BaseService {
    protected logger: Logger;
    protected metrics: Metrics;
    protected cache: Cache;
    
    constructor(container: ServiceContainer) {
        this.logger = container.get(Logger);
        this.metrics = container.get(Metrics);
        this.cache = container.get(Cache);
    }
    
    protected log(message: string): void {
        this.logger.info(message);
    }
    
    protected recordMetric(name: string, value: number): void {
        this.metrics.record(name, value);
    }
    
    protected cached<T>(key: string, fn: () => T): T {
        return this.cache.getOrSet(key, fn);
    }
}
 
class OrderService extends BaseService {
    private orderRepository: OrderRepository;
    
    constructor(container: ServiceContainer) {
        super(container); // Must call parent constructor
        this.orderRepository = container.get(OrderRepository);
    }
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        this.log('Creating order'); // Uses inherited method
        const start = Date.now();
        
        const order = await this.orderRepository.save(request.toOrder());
        
        this.recordMetric('order.created', Date.now() - start);
        return order;
    }
}
 
// Problems:
// 1. OrderService is coupled to BaseService's dependencies (logging, metrics, caching)
// 2. Adding a concern to BaseService affects ALL subclasses
// 3. Cannot have an OrderService without logging capability
// 4. Hard to test OrderService without the entire hierarchy
// 5. 'Is-a' relationship (OrderService IS-A BaseService) doesn't make semantic sense

Composition as the Solution: Composition injects concerns as dependencies rather than embedding them through inheritance:

composition-solution.ts
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
// Concerns composed, not inherited
class OrderService {
    constructor(
        private orderRepository: OrderRepository,
        private logger: Logger,           // Concern injected
        private metrics: MetricsRecorder, // Concern injected
        private cache: Cache              // Concern injected
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        this.logger.info('Creating order');
        const start = Date.now();
        
        const order = await this.orderRepository.save(request.toOrder());
        
        this.metrics.record('order.created', Date.now() - start);
        return order;
    }
}
 
// Benefits:
// 1. OrderService explicitly declares its dependencies
// 2. Each concern can be tested/replaced independently
// 3. Can create OrderService with different logging implementations
// 4. Adding concerns doesn't affect other services
// 5. Relationships make semantic sense (OrderService HAS-A Logger)
 
// Even better - use decorators for cross-cutting concerns
class OrderService {
    constructor(private orderRepository: OrderRepository) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        // Pure business logic only
        return this.orderRepository.save(request.toOrder());
    }
}
 
// Apply concerns via decoration
const orderService = new OrderService(orderRepository);
const loggedService = new LoggingDecorator(orderService);
const meteredService = new MetricsDecorator(loggedService);
const cachedService = new CachingDecorator(meteredService);
 
// Or use middleware pattern
const orderService = pipe(
    new OrderService(orderRepository),
    withLogging(logger),
    withMetrics(metrics),
    withCaching(cache)
);

When Inheritance Works

Inheritance isn't always wrong. It works well when there's a genuine 'is-a' relationship and when the hierarchy represents variations within a single concern. A PostgresRepository IS-A Repository. A DiscountedPrice IS-A Price. But a UserService IS-NOT-A LoggingBaseService.

Dependency Injection for Concern Assembly

Dependency Injection (DI) is the mechanism that makes concern isolation practical at scale. Rather than having components create or locate their dependencies, dependencies are provided ('injected') from outside. This pattern enables all the benefits of abstraction and composition we've discussed. The Three Types of Dependency Injection:

Dependency Injection Types
Type	Mechanism	When to Use	Example
Constructor Injection	Dependencies passed via constructor	Required dependencies that shouldn't change	constructor(private repo: Repository)
Method Injection	Dependencies passed per method call	Dependencies that vary per operation	execute(command, context: ExecutionContext)
Property Injection	Dependencies set after construction	Optional dependencies with defaults	@Inject() logger?: Logger

dependency-injection.ts
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
// WITHOUT DI: Hard-coded dependencies
class OrderService {
    private repository = new PostgresOrderRepository();
    private emailer = new SmtpEmailService();
    private validator = new OrderValidator();
    
    // Problems:
    // - Can't use different implementations
    // - Can't test without real database/email
    // - Can't configure dependencies
}
 
// ─────────────────────────────────────────────────────────────────
 
// WITH DI: Dependencies injected
interface OrderRepository {
    save(order: Order): Promise<void>;
    findById(id: string): Promise<Order>;
}
 
interface EmailService {
    send(email: Email): Promise<void>;
}
 
interface OrderValidator {
    validate(request: CreateOrderRequest): ValidationResult;
}
 
class OrderService {
    constructor(
        private repository: OrderRepository,  // Interface, not implementation
        private emailer: EmailService,
        private validator: OrderValidator
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        const validation = this.validator.validate(request);
        if (!validation.isValid) {
            throw new ValidationError(validation.errors);
        }
        
        const order = Order.create(request);
        await this.repository.save(order);
        await this.emailer.send(OrderConfirmationEmail.for(order));
        return order;
    }
}
 
// Production composition
const orderService = new OrderService(
    new PostgresOrderRepository(database),
    new SmtpEmailService(smtpConfig),
    new DefaultOrderValidator()
);
 
// Test composition - no external dependencies
const testService = new OrderService(
    new InMemoryOrderRepository(),
    new MockEmailService(),
    new TestOrderValidator()
);
 
// Alternative production composition
const orderService = new OrderService(
    new MongoOrderRepository(mongoClient),  // Different database
    new SendGridEmailService(apiKey),       // Different email provider
    new StrictOrderValidator()              // Stricter validation
);

DI Containers: For large applications, manually wiring dependencies becomes tedious. DI containers (also called IoC containers) automate this process by managing object creation and lifecycle:

di-container.ts
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
// Using a DI container (example with typical patterns)
import { Container, Injectable, Inject } from 'di-container';
 
@Injectable()
class PostgresOrderRepository implements OrderRepository {
    constructor(@Inject('DATABASE') private db: Database) {}
    // ...
}
 
@Injectable()
class SmtpEmailService implements EmailService {
    constructor(@Inject('SMTP_CONFIG') private config: SmtpConfig) {}
    // ...
}
 
@Injectable()
class OrderService {
    constructor(
        private repository: OrderRepository,
        private emailer: EmailService,
        private validator: OrderValidator
    ) {}
    // ...
}
 
// Container configuration
const container = new Container();
container.bind('DATABASE').toValue(postgresConnection);
container.bind('SMTP_CONFIG').toValue(smtpConfig);
container.bind(OrderRepository).to(PostgresOrderRepository);
container.bind(EmailService).to(SmtpEmailService);
container.bind(OrderValidator).to(DefaultOrderValidator);
container.bind(OrderService).toSelf();
 
// Resolution - container handles wiring
const orderService = container.get(OrderService);
// All dependencies automatically resolved

The DI Mindset

DI is a mindset more than a technology. The key insight is: a class should not know HOW to obtain its dependencies, only WHAT it needs. When you write 'new SomeService()' inside a class, you've hardcoded a dependency. When you receive it via constructor, you've declared a requirement that others fulfill.

Isolating Concerns

From Recognition to Separation

The Isolation Imperative

Encapsulation as the Foundation of Isolation

Abstraction for Concern Decoupling

Modular Decomposition

Layered Architecture for Concern Separation

Composition Over Inheritance

Dependency Injection for Concern Assembly

There’s more to understand.

Isolating Concerns

From Recognition to Separation

The Isolation Imperative

Encapsulation as the Foundation of Isolation

Abstraction for Concern Decoupling

Modular Decomposition

Layered Architecture for Concern Separation

Composition Over Inheritance

Dependency Injection for Concern Assembly

There’s more to understand.