Cross-Cutting Concerns — Separation of Concerns | OneNoughtOne

0/86

System Design (HLD)Separation of Concerns

Separation of Concerns

LevelIntermediate

Duration75 mins

TopicSeparation of Concerns

3 / 4

Cross-Cutting Concerns

The Concerns That Won't Stay Put

Some concerns refuse to respect the boundaries we've carefully constructed. Logging must happen everywhere. Security checks span every layer. Transaction management wraps operations across multiple repositories. Caching might optimize any data access. These are cross-cutting concerns —aspects of the system that naturally pervade multiple modules and layers. The challenge is profound: if we naively implement these concerns, we end up with logging code scattered across every class, security checks duplicated throughout every controller, and transaction management logic tangled with business rules. The resulting code is noisy, fragile, and violates the very separation we're trying to achieve. This page explores the nature of cross-cutting concerns and the patterns that let us address them cleanly.

What You Will Learn

By the end of this page, you will understand what makes a concern 'cross-cutting,' recognize common cross-cutting concerns in software systems, and master patterns like aspect-oriented programming, middleware pipelines, and decorators that handle these concerns without polluting business logic.

What Makes a Concern Cross-Cutting?

A cross-cutting concern is an aspect of a program that affects multiple modules and cannot be cleanly decomposed into a single location within the traditional modular structure. While functional concerns (like order processing or user management) can be isolated into dedicated modules, cross-cutting concerns inherently span those boundaries. The Tyranny of the Dominant Decomposition: Every software system is organized along a primary axis—typically by feature or business capability. This 'dominant decomposition' creates modules like OrderService, PaymentService, and UserService . But some concerns cut across all of these: Logging is needed in orders, payments, AND users Security is needed in orders, payments, AND users Performance monitoring is needed in orders, payments, AND users These concerns don't align with any single module—they align with a different axis entirely.

Characteristics of Cross-Cutting Concerns
Characteristic	Description	Example
Pervasive	Appears in many parts of the codebase	Logging statements in every service method
Repetitive	Similar code duplicated across locations	Same authorization check pattern repeated
Tangled	Interleaved with primary functionality	Transaction begin/commit wrapped around business logic
Scattered	Knowledge spread across many files	Retry policy implemented in each API client individually
Uniform	Applied consistently with similar behavior	Same structured logging format everywhere

cross-cutting-problem.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
// The Cross-Cutting Concern Problem
// Notice how logging, security, timing, and transactions appear EVERYWHERE
 
class OrderService {
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        const startTime = Date.now();                    // TIMING
        this.logger.info('Creating order', { request }); // LOGGING
        
        this.security.requirePermission('orders:create'); // SECURITY
        
        const tx = await this.db.beginTransaction();      // TRANSACTION
        try {
            const order = Order.create(request);
            await this.orderRepository.save(order, tx);
            await tx.commit();                            // TRANSACTION
            
            this.logger.info('Order created', { orderId: order.id }); // LOGGING
            this.metrics.record('order.created', Date.now() - startTime); // TIMING
            
            return order;
        } catch (error) {
            await tx.rollback();                          // TRANSACTION
            this.logger.error('Order creation failed', { error }); // LOGGING
            throw error;
        }
    }
}
 
class PaymentService {
    async processPayment(payment: Payment): Promise<void> {
        const startTime = Date.now();                    // TIMING (repeated)
        this.logger.info('Processing payment', { payment }); // LOGGING (repeated)
        
        this.security.requirePermission('payments:process'); // SECURITY (repeated)
        
        const tx = await this.db.beginTransaction();      // TRANSACTION (repeated)
        try {
            await this.paymentGateway.charge(payment);
            await this.paymentRepository.save(payment, tx);
            await tx.commit();                            // TRANSACTION (repeated)
            
            this.logger.info('Payment processed', { id: payment.id }); // LOGGING (repeated)
            this.metrics.record('payment.processed', Date.now() - startTime); // TIMING (repeated)
        } catch (error) {
            await tx.rollback();                          // TRANSACTION (repeated)
            this.logger.error('Payment failed', { error }); // LOGGING (repeated)
            throw error;
        }
    }
}
 
// Problems:
// 1. SCATTERED: Same patterns repeated across every service
// 2. TANGLED: Business logic buried under infrastructure code
// 3. NOISY: Hard to see the actual business logic
// 4. FRAGILE: Change logging format? Edit 100 files
// 5. ERROR-PRONE: Easy to forget transaction/security in new code

The Core Problem

When cross-cutting concerns are implemented naively, business logic drowns in infrastructure code. A method that should be 5 lines becomes 25 lines. The 'what' of the code (create an order) is obscured by the 'how' of all the surrounding machinery. This is the tangling and scattering that separation of concerns aims to eliminate.

Catalog of Common Cross-Cutting Concerns

While every application has unique concerns, certain cross-cutting concerns appear so frequently that they constitute a standard catalog. Recognizing these patterns helps you anticipate infrastructure needs early and design appropriate solutions.

Infrastructure Cross-Cutting Concerns

•Logging — Recording events, errors, and diagnostic information. Every operation might need logging at entry, exit, and error points.
•Metrics/Monitoring — Collecting quantitative data about system behavior: latencies, throughput, error rates, resource utilization.
•Tracing — Tracking requests across distributed services with correlation IDs and distributed tracing spans.
•Error Handling — Consistent categorization, transformation, and reporting of exceptions across the system.
•Retry Policies — Automatic retry with backoff for transient failures in I/O operations, API calls, etc.
•Circuit Breaking — Failing fast when downstream dependencies are unhealthy to prevent cascade failures.
•Caching — Storing and retrieving computed results to avoid redundant work. Applied to many different data access paths.

Security Cross-Cutting Concerns

•Authentication — Verifying identity claims on incoming requests before any business logic executes.
•Authorization — Enforcing access control policies to determine if authenticated users can perform specific actions.
•Audit Logging — Recording security-relevant events for compliance and forensic purposes.
•Input Validation — Sanitizing and validating all incoming data to prevent injection attacks and data corruption.
•Encryption — Protecting sensitive data at rest and in transit across all storage and communication channels.
•Rate Limiting — Protecting against abuse by limiting request frequencies per client/user.

Data Cross-Cutting Concerns

•Transaction Management — Ensuring atomicity and consistency of operations that span multiple data modifications.
•Connection Pooling — Managing database and network connections efficiently across all data access code.
•Multi-Tenancy — Ensuring data isolation and proper tenant context across all queries and mutations.
•Soft Delete — Implementing logical deletion (marking records instead of removing) across entity types.
•Auditing/Timestamps — Automatically recording created_at, updated_at, created_by fields on all entities.

The Cross-Cutting Concern Test

If you find yourself copy-pasting similar code patterns into many classes, or if changing a policy requires editing many files, you've likely discovered a cross-cutting concern that deserves dedicated treatment.

The Decorator Pattern for Cross-Cutting Concerns

The Decorator Pattern wraps objects to add behavior without modifying their implementation. For cross-cutting concerns, decorators let us layer additional functionality (logging, caching, security) around core business logic while keeping each concern in a single, reusable class. How Decorators Work: A decorator implements the same interface as the object it wraps, adding its behavior before/after delegating to the wrapped object:

decorator-pattern.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
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
// Core concern: Order service interface
interface OrderService {
    createOrder(request: CreateOrderRequest): Promise<Order>;
    findById(id: string): Promise<Order>;
}
 
// Primary implementation - pure business logic, no infrastructure
class OrderServiceImpl implements OrderService {
    constructor(private repository: OrderRepository) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        const order = Order.create(request);
        await this.repository.save(order);
        return order;
    }
    
    async findById(id: string): Promise<Order> {
        return this.repository.findById(id);
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Logging decorator - adds logging concern
class LoggingOrderServiceDecorator implements OrderService {
    constructor(
        private wrapped: OrderService,
        private logger: Logger
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        this.logger.info('Creating order', { request });
        try {
            const order = await this.wrapped.createOrder(request);
            this.logger.info('Order created', { orderId: order.id });
            return order;
        } catch (error) {
            this.logger.error('Order creation failed', { error });
            throw error;
        }
    }
    
    async findById(id: string): Promise<Order> {
        this.logger.info('Finding order', { id });
        return this.wrapped.findById(id);
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Metrics decorator - adds timing/metrics concern
class MetricsOrderServiceDecorator implements OrderService {
    constructor(
        private wrapped: OrderService,
        private metrics: MetricsRecorder
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        const timer = this.metrics.startTimer('order.create');
        try {
            const result = await this.wrapped.createOrder(request);
            timer.success();
            return result;
        } catch (error) {
            timer.failure();
            throw error;
        }
    }
    
    async findById(id: string): Promise<Order> {
        return this.metrics.time('order.findById', () => 
            this.wrapped.findById(id)
        );
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Authorization decorator - adds security concern
class AuthorizingOrderServiceDecorator implements OrderService {
    constructor(
        private wrapped: OrderService,
        private authz: AuthorizationService
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        await this.authz.requirePermission('orders:create');
        return this.wrapped.createOrder(request);
    }
    
    async findById(id: string): Promise<Order> {
        const order = await this.wrapped.findById(id);
        await this.authz.requireAccessToResource('order', order.id);
        return order;
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Composition - stack decorators to add concerns
const orderService = new AuthorizingOrderServiceDecorator(
    new MetricsOrderServiceDecorator(
        new LoggingOrderServiceDecorator(
            new OrderServiceImpl(repository),
            logger
        ),
        metrics
    ),
    authz
);
 
// Order of decoration matters! 
// Request flow: Authz → Metrics → Logging → Core → Logging → Metrics → Authz

Decorator Benefits

•Each concern in its own class
•Business logic stays clean
•Decorators are reusable
•Easy to test each layer
•Concerns can be added/removed
•Composition is explicit

Decorator Limitations

•Boilerplate in each decorator
•Must match entire interface
•Nesting can get deep
•Order matters and can confuse
•Manual wiring is tedious
•Type system may not help much

Generic Decorators

In TypeScript or languages with generics, you can create reusable decorator factories that wrap any service implementing a common pattern. This reduces boilerplate significantly while maintaining type safety.

Middleware and Pipeline Architectures

Middleware (also called interceptors or filters) provides a powerful pattern for cross-cutting concerns, especially in request/response processing. Unlike decorators that wrap specific objects, middleware operates on the flow of data through the system, with each middleware processing requests before/after the next handler. The Pipeline Pattern: Middleware forms a pipeline through which requests flow. Each middleware can: Inspect and modify the incoming request Execute the next handler in the chain Inspect and modify the outgoing response Short-circuit the pipeline entirely

middleware-pattern.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
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
121
// Middleware type definition
type Middleware<TRequest, TResponse> = (
    request: TRequest,
    next: () => Promise<TResponse>
) => Promise<TResponse>;
 
// Logging middleware
const loggingMiddleware: Middleware<Request, Response> = async (req, next) => {
    console.log(`[REQ] ${req.method} ${req.path}`);
    const start = Date.now();
    
    try {
        const response = await next();
        console.log(`[RES] ${req.path} - ${response.status} in ${Date.now() - start}ms`);
        return response;
    } catch (error) {
        console.error(`[ERR] ${req.path} - ${error.message}`);
        throw error;
    }
};
 
// Authentication middleware
const authMiddleware: Middleware<Request, Response> = async (req, next) => {
    const token = req.headers.authorization;
    if (!token) {
        return Response.unauthorized('Missing token');
    }
    
    const user = await authService.validateToken(token);
    if (!user) {
        return Response.unauthorized('Invalid token');
    }
    
    req.context.user = user; // Attach user to request context
    return next();
};
 
// Rate limiting middleware
const rateLimitMiddleware: Middleware<Request, Response> = async (req, next) => {
    const clientId = req.ip;
    const allowed = await rateLimiter.checkLimit(clientId);
    
    if (!allowed) {
        return Response.tooManyRequests();
    }
    
    return next();
};
 
// Error handling middleware
const errorMiddleware: Middleware<Request, Response> = async (req, next) => {
    try {
        return await next();
    } catch (error) {
        if (error instanceof ValidationError) {
            return Response.badRequest(error.message);
        }
        if (error instanceof NotFoundError) {
            return Response.notFound(error.message);
        }
        // Log unexpected errors
        console.error('Unexpected error:', error);
        return Response.internalError();
    }
};
 
// Transaction middleware
const transactionMiddleware: Middleware<Request, Response> = async (req, next) => {
    const tx = await database.beginTransaction();
    req.context.transaction = tx;
    
    try {
        const response = await next();
        await tx.commit();
        return response;
    } catch (error) {
        await tx.rollback();
        throw error;
    }
};
 
// ─────────────────────────────────────────────────────────────────
 
// Pipeline composition
class Pipeline<TReq, TRes> {
    private middlewares: Middleware<TReq, TRes>[] = [];
    
    use(middleware: Middleware<TReq, TRes>): this {
        this.middlewares.push(middleware);
        return this;
    }
    
    async execute(request: TReq, handler: (req: TReq) => Promise<TRes>): Promise<TRes> {
        let index = 0;
        
        const next = async (): Promise<TRes> => {
            if (index < this.middlewares.length) {
                const middleware = this.middlewares[index++];
                return middleware(request, next);
            }
            return handler(request);
        };
        
        return next();
    }
}
 
// Configure pipeline
const pipeline = new Pipeline<Request, Response>()
    .use(errorMiddleware)     // Outermost - catches all errors
    .use(loggingMiddleware)   // Log all requests
    .use(rateLimitMiddleware) // Reject excessive requests
    .use(authMiddleware)      // Authenticate the request
    .use(transactionMiddleware); // Wrap in transaction
 
// Execute request through pipeline
const response = await pipeline.execute(request, async (req) => {
    // This handler contains ONLY business logic
    const order = await orderService.createOrder(req.body);
    return Response.created(order);
});

Middleware in Frameworks

Most web frameworks (Express, Koa, FastAPI, ASP.NET Core) provide built-in middleware pipelines. Understanding this pattern helps you use framework middleware effectively and know when to create custom middleware for your specific cross-cutting concerns.

Aspect-Oriented Programming (AOP)

Aspect-Oriented Programming (AOP) is a programming paradigm specifically designed to address cross-cutting concerns. AOP introduces new constructs— aspects, pointcuts, and advice —that let you define cross-cutting behavior once and apply it across many locations automatically. AOP Terminology:

Core AOP Concepts
Concept	Definition	Example
Aspect	A modular unit of cross-cutting behavior	LoggingAspect, SecurityAspect, TransactionAspect
Join Point	A point in program execution where aspect can be applied	Method call, field access, object creation
Pointcut	An expression selecting join points	'All methods in *Service classes starting with create'
Advice	Code to execute at matched join points	Before, After, Around, AfterReturning, AfterThrowing
Weaving	Process of applying aspects to code	Compile-time, load-time, or runtime weaving

aop-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
76
// AOP with TypeScript decorators (simplified conceptual example)
// Real AOP frameworks provide more powerful pointcut expressions
 
// Aspect definition using decorators
@Aspect()
class LoggingAspect {
    @Before('execution(* *Service.*(..))')
    logMethodEntry(context: JoinPointContext) {
        console.log(`Entering ${context.className}.${context.methodName}`);
        console.log('Arguments:', context.args);
    }
    
    @AfterReturning('execution(* *Service.*(..))')
    logMethodSuccess(context: JoinPointContext, result: any) {
        console.log(`${context.methodName} returned:`, result);
    }
    
    @AfterThrowing('execution(* *Service.*(..))')
    logMethodError(context: JoinPointContext, error: Error) {
        console.error(`${context.methodName} threw:`, error);
    }
}
 
@Aspect()
class TransactionAspect {
    @Around('execution(* *Repository.save*(..))')
    async wrapInTransaction(context: ProceedingJoinPointContext): Promise<any> {
        const tx = await this.db.beginTransaction();
        try {
            const result = await context.proceed(); // Execute original method
            await tx.commit();
            return result;
        } catch (error) {
            await tx.rollback();
            throw error;
        }
    }
}
 
@Aspect()
class SecurityAspect {
    @Before('execution(* @Secured *Service.*(..))')
    checkPermissions(context: JoinPointContext) {
        const requiredRole = context.metadata.get('role');
        if (!this.authz.hasRole(context.principal, requiredRole)) {
            throw new UnauthorizedError();
        }
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Target class - completely clean, no cross-cutting code
class OrderService {
    constructor(private repository: OrderRepository) {}
    
    @Secured({ role: 'orders:write' })
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        // Pure business logic
        const order = Order.create(request);
        await this.repository.save(order);
        return order;
    }
    
    async findById(id: string): Promise<Order> {
        return this.repository.findById(id);
    }
}
 
// After weaving, calls to OrderService.createOrder automatically:
// 1. Log method entry (LoggingAspect)
// 2. Check security permissions (SecurityAspect)
// 3. Execute the method
// 4. Log success or failure (LoggingAspect)
 
// Target class remains clean; cross-cutting behavior injected by AOP

How AOP Weaving Works: AOP frameworks inject aspect behavior through various weaving strategies: Compile-time weaving — Aspects are woven into bytecode during compilation (AspectJ) Load-time weaving — Aspects are woven when classes are loaded (AspectJ LTW) Runtime weaving — Proxies intercept calls at runtime (Spring AOP) Decorator-based — TypeScript decorators approximate AOP behavior

AOP Tradeoffs

AOP is powerful but can make code harder to understand. When reading orderService.createOrder(), you can't tell what actually executes without knowing the active aspects. Use AOP judiciously—typically for truly universal concerns (logging, transactions). Don't use it to hide business logic.

Event-Driven Approaches to Cross-Cutting

Event-driven architecture offers another approach to cross-cutting concerns: rather than wrapping business logic with additional behavior, business logic emits events that separate handlers process. This inverts control—the core code doesn't even know what cross-cutting concerns exist. The Pattern: Core business operations emit domain events. Separate event handlers (often in different modules) react to those events to implement cross-cutting behavior:

event-driven-cross-cutting.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
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
121
// Domain events
class OrderCreatedEvent {
    constructor(
        public readonly orderId: string,
        public readonly userId: string,
        public readonly items: OrderItem[],
        public readonly total: Money,
        public readonly timestamp: Date
    ) {}
}
 
class OrderCancelledEvent {
    constructor(
        public readonly orderId: string,
        public readonly reason: string,
        public readonly timestamp: Date
    ) {}
}
 
// Core service - emits events but doesn't handle cross-cutting concerns
class OrderService {
    constructor(
        private repository: OrderRepository,
        private eventBus: EventBus
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        // Pure business logic
        const order = Order.create(request);
        await this.repository.save(order);
        
        // Emit event - what happens next is not this class's concern
        await this.eventBus.publish(new OrderCreatedEvent(
            order.id,
            request.userId,
            order.items,
            order.total,
            new Date()
        ));
        
        return order;
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Cross-cutting concerns as event handlers
 
// Logging handler
@EventHandler()
class OrderLoggingHandler {
    @On(OrderCreatedEvent)
    async logOrderCreated(event: OrderCreatedEvent) {
        this.logger.info('Order created', {
            orderId: event.orderId,
            userId: event.userId,
            total: event.total.toString()
        });
    }
    
    @On(OrderCancelledEvent)
    async logOrderCancelled(event: OrderCancelledEvent) {
        this.logger.info('Order cancelled', {
            orderId: event.orderId,
            reason: event.reason
        });
    }
}
 
// Analytics handler
@EventHandler()
class OrderAnalyticsHandler {
    @On(OrderCreatedEvent)
    async trackOrderCreated(event: OrderCreatedEvent) {
        await this.analytics.track('order_created', {
            orderId: event.orderId,
            value: event.total.toNumber(),
            itemCount: event.items.length
        });
    }
}
 
// Notification handler
@EventHandler()
class OrderNotificationHandler {
    @On(OrderCreatedEvent)
    async sendConfirmation(event: OrderCreatedEvent) {
        const user = await this.userRepository.findById(event.userId);
        await this.mailer.send({
            to: user.email,
            template: 'order-confirmation',
            data: { orderId: event.orderId, total: event.total }
        });
    }
}
 
// Inventory handler
@EventHandler()
class InventoryHandler {
    @On(OrderCreatedEvent)
    async reserveInventory(event: OrderCreatedEvent) {
        for (const item of event.items) {
            await this.inventory.reserve(item.productId, item.quantity);
        }
    }
    
    @On(OrderCancelledEvent)
    async releaseInventory(event: OrderCancelledEvent) {
        const order = await this.orderRepository.findById(event.orderId);
        for (const item of order.items) {
            await this.inventory.release(item.productId, item.quantity);
        }
    }
}
 
// Benefits:
// 1. OrderService is clean - just business logic
// 2. Each handler is a single responsibility
// 3. Adding concerns doesn't modify OrderService
// 4. Handlers can fail independently (with appropriate handling)
// 5. Handlers can run asynchronously if appropriate

Event-Driven Benefits

•Complete decoupling of concerns
•Easy to add/remove handlers
•Handlers can be async
•Natural for distributed systems
•Core code stays pure
•Easy to test handlers independently

Event-Driven Limitations

•Hard to trace full behavior
•Event schema must be stable
•Handler failures need handling
•Ordering can be complex
•Not suitable for sync requirements
•Can lead to event storms

When to Use Events

Event-driven approaches work best when cross-cutting handlers can tolerate eventual consistency and potential failures. Logging, analytics, and notifications are excellent candidates. Authorization checks that must happen synchronously are not—use middleware or decorators for those.

Choosing the Right Approach

Each approach to cross-cutting concerns has its strengths. The right choice depends on your specific situation:

Cross-Cutting Concern Approach Selection
Approach	Best For	Avoid When
Decorators	Object-level wrapping, explicit composition, testability	Interface has many methods, need DRY across many types
Middleware/Pipeline	Request/response processing, HTTP concerns, ordered processing	Fine-grained method-level concerns, non-request contexts
AOP	Universal concerns, compile-time optimization, minimal code intrusion	Team unfamiliar with AOP, need explicit behavior, debugging priority
Event-Driven	Async side effects, multiple independent handlers, loose coupling	Sync requirements, ordering matters, need guaranteed execution

approach-selection.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
// DECISION FRAMEWORK for Cross-Cutting Concern Implementation
 
// Q1: Does the concern need to MODIFY the request/response?
//     YES → Middleware/Decorators
//     NO  → Could use events
 
// Q2: Must the concern execute SYNCHRONOUSLY with the operation?
//     YES → Middleware/Decorators/AOP
//     NO  → Events are a good option
 
// Q3: Does the concern apply UNIVERSALLY across many operations?
//     YES → AOP or Middleware at infrastructure level
//     NO  → Decorators for selective application
 
// Q4: Is EXPLICIT composition important for understanding/debugging?
//     YES → Decorators or Middleware (visible in composition)
//     NO  → AOP is acceptable
 
// ─────────────────────────────────────────────────────────────────
 
// Example: Implementing the same concern different ways
 
// AUTHENTICATION
// - Must be sync ✓
// - Modifies request (adds user context) ✓
// - Applies to most requests ✓
// → Best: Middleware
 
// AUDIT LOGGING
// - Can be async ✓
// - Doesn't modify response ✓
// - Applies after operations complete ✓
// → Best: Events or AOP
 
// CACHING
// - Must be sync (to return cached value) ✓
// - Modifies response (returns cached instead of fresh) ✓
// - Selective application ✓
// → Best: Decorators
 
// TRANSACTION MANAGEMENT
// - Must be sync ✓
// - Wraps around operation ✓
// - Applies to database operations universally ✓
// → Best: AOP or Decorators

Mix and Match

Real systems often combine approaches. You might use middleware for HTTP-level concerns (auth, rate limiting), decorators for service-level concerns (caching, retries), and events for post-operation concerns (notifications, analytics). Choose the right tool for each specific concern.

System Design (HLD)Separation of Concerns

Separation of Concerns

LevelIntermediate

Duration75 mins

TopicSeparation of Concerns

3 / 4

Cross-Cutting Concerns

The Concerns That Won't Stay Put

Some concerns refuse to respect the boundaries we've carefully constructed. Logging must happen everywhere. Security checks span every layer. Transaction management wraps operations across multiple repositories. Caching might optimize any data access. These are cross-cutting concerns —aspects of the system that naturally pervade multiple modules and layers. The challenge is profound: if we naively implement these concerns, we end up with logging code scattered across every class, security checks duplicated throughout every controller, and transaction management logic tangled with business rules. The resulting code is noisy, fragile, and violates the very separation we're trying to achieve. This page explores the nature of cross-cutting concerns and the patterns that let us address them cleanly.

What You Will Learn

By the end of this page, you will understand what makes a concern 'cross-cutting,' recognize common cross-cutting concerns in software systems, and master patterns like aspect-oriented programming, middleware pipelines, and decorators that handle these concerns without polluting business logic.

What Makes a Concern Cross-Cutting?

A cross-cutting concern is an aspect of a program that affects multiple modules and cannot be cleanly decomposed into a single location within the traditional modular structure. While functional concerns (like order processing or user management) can be isolated into dedicated modules, cross-cutting concerns inherently span those boundaries. The Tyranny of the Dominant Decomposition: Every software system is organized along a primary axis—typically by feature or business capability. This 'dominant decomposition' creates modules like OrderService, PaymentService, and UserService . But some concerns cut across all of these: Logging is needed in orders, payments, AND users Security is needed in orders, payments, AND users Performance monitoring is needed in orders, payments, AND users These concerns don't align with any single module—they align with a different axis entirely.

Characteristics of Cross-Cutting Concerns
Characteristic	Description	Example
Pervasive	Appears in many parts of the codebase	Logging statements in every service method
Repetitive	Similar code duplicated across locations	Same authorization check pattern repeated
Tangled	Interleaved with primary functionality	Transaction begin/commit wrapped around business logic
Scattered	Knowledge spread across many files	Retry policy implemented in each API client individually
Uniform	Applied consistently with similar behavior	Same structured logging format everywhere

cross-cutting-problem.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
// The Cross-Cutting Concern Problem
// Notice how logging, security, timing, and transactions appear EVERYWHERE
 
class OrderService {
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        const startTime = Date.now();                    // TIMING
        this.logger.info('Creating order', { request }); // LOGGING
        
        this.security.requirePermission('orders:create'); // SECURITY
        
        const tx = await this.db.beginTransaction();      // TRANSACTION
        try {
            const order = Order.create(request);
            await this.orderRepository.save(order, tx);
            await tx.commit();                            // TRANSACTION
            
            this.logger.info('Order created', { orderId: order.id }); // LOGGING
            this.metrics.record('order.created', Date.now() - startTime); // TIMING
            
            return order;
        } catch (error) {
            await tx.rollback();                          // TRANSACTION
            this.logger.error('Order creation failed', { error }); // LOGGING
            throw error;
        }
    }
}
 
class PaymentService {
    async processPayment(payment: Payment): Promise<void> {
        const startTime = Date.now();                    // TIMING (repeated)
        this.logger.info('Processing payment', { payment }); // LOGGING (repeated)
        
        this.security.requirePermission('payments:process'); // SECURITY (repeated)
        
        const tx = await this.db.beginTransaction();      // TRANSACTION (repeated)
        try {
            await this.paymentGateway.charge(payment);
            await this.paymentRepository.save(payment, tx);
            await tx.commit();                            // TRANSACTION (repeated)
            
            this.logger.info('Payment processed', { id: payment.id }); // LOGGING (repeated)
            this.metrics.record('payment.processed', Date.now() - startTime); // TIMING (repeated)
        } catch (error) {
            await tx.rollback();                          // TRANSACTION (repeated)
            this.logger.error('Payment failed', { error }); // LOGGING (repeated)
            throw error;
        }
    }
}
 
// Problems:
// 1. SCATTERED: Same patterns repeated across every service
// 2. TANGLED: Business logic buried under infrastructure code
// 3. NOISY: Hard to see the actual business logic
// 4. FRAGILE: Change logging format? Edit 100 files
// 5. ERROR-PRONE: Easy to forget transaction/security in new code

The Core Problem

When cross-cutting concerns are implemented naively, business logic drowns in infrastructure code. A method that should be 5 lines becomes 25 lines. The 'what' of the code (create an order) is obscured by the 'how' of all the surrounding machinery. This is the tangling and scattering that separation of concerns aims to eliminate.

Catalog of Common Cross-Cutting Concerns

While every application has unique concerns, certain cross-cutting concerns appear so frequently that they constitute a standard catalog. Recognizing these patterns helps you anticipate infrastructure needs early and design appropriate solutions.

Infrastructure Cross-Cutting Concerns

•Logging — Recording events, errors, and diagnostic information. Every operation might need logging at entry, exit, and error points.
•Metrics/Monitoring — Collecting quantitative data about system behavior: latencies, throughput, error rates, resource utilization.
•Tracing — Tracking requests across distributed services with correlation IDs and distributed tracing spans.
•Error Handling — Consistent categorization, transformation, and reporting of exceptions across the system.
•Retry Policies — Automatic retry with backoff for transient failures in I/O operations, API calls, etc.
•Circuit Breaking — Failing fast when downstream dependencies are unhealthy to prevent cascade failures.
•Caching — Storing and retrieving computed results to avoid redundant work. Applied to many different data access paths.

Security Cross-Cutting Concerns

•Authentication — Verifying identity claims on incoming requests before any business logic executes.
•Authorization — Enforcing access control policies to determine if authenticated users can perform specific actions.
•Audit Logging — Recording security-relevant events for compliance and forensic purposes.
•Input Validation — Sanitizing and validating all incoming data to prevent injection attacks and data corruption.
•Encryption — Protecting sensitive data at rest and in transit across all storage and communication channels.
•Rate Limiting — Protecting against abuse by limiting request frequencies per client/user.

Data Cross-Cutting Concerns

•Transaction Management — Ensuring atomicity and consistency of operations that span multiple data modifications.
•Connection Pooling — Managing database and network connections efficiently across all data access code.
•Multi-Tenancy — Ensuring data isolation and proper tenant context across all queries and mutations.
•Soft Delete — Implementing logical deletion (marking records instead of removing) across entity types.
•Auditing/Timestamps — Automatically recording created_at, updated_at, created_by fields on all entities.

The Cross-Cutting Concern Test

If you find yourself copy-pasting similar code patterns into many classes, or if changing a policy requires editing many files, you've likely discovered a cross-cutting concern that deserves dedicated treatment.

The Decorator Pattern for Cross-Cutting Concerns

The Decorator Pattern wraps objects to add behavior without modifying their implementation. For cross-cutting concerns, decorators let us layer additional functionality (logging, caching, security) around core business logic while keeping each concern in a single, reusable class. How Decorators Work: A decorator implements the same interface as the object it wraps, adding its behavior before/after delegating to the wrapped object:

decorator-pattern.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
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
// Core concern: Order service interface
interface OrderService {
    createOrder(request: CreateOrderRequest): Promise<Order>;
    findById(id: string): Promise<Order>;
}
 
// Primary implementation - pure business logic, no infrastructure
class OrderServiceImpl implements OrderService {
    constructor(private repository: OrderRepository) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        const order = Order.create(request);
        await this.repository.save(order);
        return order;
    }
    
    async findById(id: string): Promise<Order> {
        return this.repository.findById(id);
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Logging decorator - adds logging concern
class LoggingOrderServiceDecorator implements OrderService {
    constructor(
        private wrapped: OrderService,
        private logger: Logger
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        this.logger.info('Creating order', { request });
        try {
            const order = await this.wrapped.createOrder(request);
            this.logger.info('Order created', { orderId: order.id });
            return order;
        } catch (error) {
            this.logger.error('Order creation failed', { error });
            throw error;
        }
    }
    
    async findById(id: string): Promise<Order> {
        this.logger.info('Finding order', { id });
        return this.wrapped.findById(id);
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Metrics decorator - adds timing/metrics concern
class MetricsOrderServiceDecorator implements OrderService {
    constructor(
        private wrapped: OrderService,
        private metrics: MetricsRecorder
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        const timer = this.metrics.startTimer('order.create');
        try {
            const result = await this.wrapped.createOrder(request);
            timer.success();
            return result;
        } catch (error) {
            timer.failure();
            throw error;
        }
    }
    
    async findById(id: string): Promise<Order> {
        return this.metrics.time('order.findById', () => 
            this.wrapped.findById(id)
        );
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Authorization decorator - adds security concern
class AuthorizingOrderServiceDecorator implements OrderService {
    constructor(
        private wrapped: OrderService,
        private authz: AuthorizationService
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        await this.authz.requirePermission('orders:create');
        return this.wrapped.createOrder(request);
    }
    
    async findById(id: string): Promise<Order> {
        const order = await this.wrapped.findById(id);
        await this.authz.requireAccessToResource('order', order.id);
        return order;
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Composition - stack decorators to add concerns
const orderService = new AuthorizingOrderServiceDecorator(
    new MetricsOrderServiceDecorator(
        new LoggingOrderServiceDecorator(
            new OrderServiceImpl(repository),
            logger
        ),
        metrics
    ),
    authz
);
 
// Order of decoration matters! 
// Request flow: Authz → Metrics → Logging → Core → Logging → Metrics → Authz

Decorator Benefits

•Each concern in its own class
•Business logic stays clean
•Decorators are reusable
•Easy to test each layer
•Concerns can be added/removed
•Composition is explicit

Decorator Limitations

•Boilerplate in each decorator
•Must match entire interface
•Nesting can get deep
•Order matters and can confuse
•Manual wiring is tedious
•Type system may not help much

Generic Decorators

In TypeScript or languages with generics, you can create reusable decorator factories that wrap any service implementing a common pattern. This reduces boilerplate significantly while maintaining type safety.

Middleware and Pipeline Architectures

Middleware (also called interceptors or filters) provides a powerful pattern for cross-cutting concerns, especially in request/response processing. Unlike decorators that wrap specific objects, middleware operates on the flow of data through the system, with each middleware processing requests before/after the next handler. The Pipeline Pattern: Middleware forms a pipeline through which requests flow. Each middleware can: Inspect and modify the incoming request Execute the next handler in the chain Inspect and modify the outgoing response Short-circuit the pipeline entirely

middleware-pattern.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
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
121
// Middleware type definition
type Middleware<TRequest, TResponse> = (
    request: TRequest,
    next: () => Promise<TResponse>
) => Promise<TResponse>;
 
// Logging middleware
const loggingMiddleware: Middleware<Request, Response> = async (req, next) => {
    console.log(`[REQ] ${req.method} ${req.path}`);
    const start = Date.now();
    
    try {
        const response = await next();
        console.log(`[RES] ${req.path} - ${response.status} in ${Date.now() - start}ms`);
        return response;
    } catch (error) {
        console.error(`[ERR] ${req.path} - ${error.message}`);
        throw error;
    }
};
 
// Authentication middleware
const authMiddleware: Middleware<Request, Response> = async (req, next) => {
    const token = req.headers.authorization;
    if (!token) {
        return Response.unauthorized('Missing token');
    }
    
    const user = await authService.validateToken(token);
    if (!user) {
        return Response.unauthorized('Invalid token');
    }
    
    req.context.user = user; // Attach user to request context
    return next();
};
 
// Rate limiting middleware
const rateLimitMiddleware: Middleware<Request, Response> = async (req, next) => {
    const clientId = req.ip;
    const allowed = await rateLimiter.checkLimit(clientId);
    
    if (!allowed) {
        return Response.tooManyRequests();
    }
    
    return next();
};
 
// Error handling middleware
const errorMiddleware: Middleware<Request, Response> = async (req, next) => {
    try {
        return await next();
    } catch (error) {
        if (error instanceof ValidationError) {
            return Response.badRequest(error.message);
        }
        if (error instanceof NotFoundError) {
            return Response.notFound(error.message);
        }
        // Log unexpected errors
        console.error('Unexpected error:', error);
        return Response.internalError();
    }
};
 
// Transaction middleware
const transactionMiddleware: Middleware<Request, Response> = async (req, next) => {
    const tx = await database.beginTransaction();
    req.context.transaction = tx;
    
    try {
        const response = await next();
        await tx.commit();
        return response;
    } catch (error) {
        await tx.rollback();
        throw error;
    }
};
 
// ─────────────────────────────────────────────────────────────────
 
// Pipeline composition
class Pipeline<TReq, TRes> {
    private middlewares: Middleware<TReq, TRes>[] = [];
    
    use(middleware: Middleware<TReq, TRes>): this {
        this.middlewares.push(middleware);
        return this;
    }
    
    async execute(request: TReq, handler: (req: TReq) => Promise<TRes>): Promise<TRes> {
        let index = 0;
        
        const next = async (): Promise<TRes> => {
            if (index < this.middlewares.length) {
                const middleware = this.middlewares[index++];
                return middleware(request, next);
            }
            return handler(request);
        };
        
        return next();
    }
}
 
// Configure pipeline
const pipeline = new Pipeline<Request, Response>()
    .use(errorMiddleware)     // Outermost - catches all errors
    .use(loggingMiddleware)   // Log all requests
    .use(rateLimitMiddleware) // Reject excessive requests
    .use(authMiddleware)      // Authenticate the request
    .use(transactionMiddleware); // Wrap in transaction
 
// Execute request through pipeline
const response = await pipeline.execute(request, async (req) => {
    // This handler contains ONLY business logic
    const order = await orderService.createOrder(req.body);
    return Response.created(order);
});

Middleware in Frameworks

Most web frameworks (Express, Koa, FastAPI, ASP.NET Core) provide built-in middleware pipelines. Understanding this pattern helps you use framework middleware effectively and know when to create custom middleware for your specific cross-cutting concerns.

Aspect-Oriented Programming (AOP)

Aspect-Oriented Programming (AOP) is a programming paradigm specifically designed to address cross-cutting concerns. AOP introduces new constructs— aspects, pointcuts, and advice —that let you define cross-cutting behavior once and apply it across many locations automatically. AOP Terminology:

Core AOP Concepts
Concept	Definition	Example
Aspect	A modular unit of cross-cutting behavior	LoggingAspect, SecurityAspect, TransactionAspect
Join Point	A point in program execution where aspect can be applied	Method call, field access, object creation
Pointcut	An expression selecting join points	'All methods in *Service classes starting with create'
Advice	Code to execute at matched join points	Before, After, Around, AfterReturning, AfterThrowing
Weaving	Process of applying aspects to code	Compile-time, load-time, or runtime weaving

aop-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
76
// AOP with TypeScript decorators (simplified conceptual example)
// Real AOP frameworks provide more powerful pointcut expressions
 
// Aspect definition using decorators
@Aspect()
class LoggingAspect {
    @Before('execution(* *Service.*(..))')
    logMethodEntry(context: JoinPointContext) {
        console.log(`Entering ${context.className}.${context.methodName}`);
        console.log('Arguments:', context.args);
    }
    
    @AfterReturning('execution(* *Service.*(..))')
    logMethodSuccess(context: JoinPointContext, result: any) {
        console.log(`${context.methodName} returned:`, result);
    }
    
    @AfterThrowing('execution(* *Service.*(..))')
    logMethodError(context: JoinPointContext, error: Error) {
        console.error(`${context.methodName} threw:`, error);
    }
}
 
@Aspect()
class TransactionAspect {
    @Around('execution(* *Repository.save*(..))')
    async wrapInTransaction(context: ProceedingJoinPointContext): Promise<any> {
        const tx = await this.db.beginTransaction();
        try {
            const result = await context.proceed(); // Execute original method
            await tx.commit();
            return result;
        } catch (error) {
            await tx.rollback();
            throw error;
        }
    }
}
 
@Aspect()
class SecurityAspect {
    @Before('execution(* @Secured *Service.*(..))')
    checkPermissions(context: JoinPointContext) {
        const requiredRole = context.metadata.get('role');
        if (!this.authz.hasRole(context.principal, requiredRole)) {
            throw new UnauthorizedError();
        }
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Target class - completely clean, no cross-cutting code
class OrderService {
    constructor(private repository: OrderRepository) {}
    
    @Secured({ role: 'orders:write' })
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        // Pure business logic
        const order = Order.create(request);
        await this.repository.save(order);
        return order;
    }
    
    async findById(id: string): Promise<Order> {
        return this.repository.findById(id);
    }
}
 
// After weaving, calls to OrderService.createOrder automatically:
// 1. Log method entry (LoggingAspect)
// 2. Check security permissions (SecurityAspect)
// 3. Execute the method
// 4. Log success or failure (LoggingAspect)
 
// Target class remains clean; cross-cutting behavior injected by AOP

How AOP Weaving Works: AOP frameworks inject aspect behavior through various weaving strategies: Compile-time weaving — Aspects are woven into bytecode during compilation (AspectJ) Load-time weaving — Aspects are woven when classes are loaded (AspectJ LTW) Runtime weaving — Proxies intercept calls at runtime (Spring AOP) Decorator-based — TypeScript decorators approximate AOP behavior

AOP Tradeoffs

AOP is powerful but can make code harder to understand. When reading orderService.createOrder(), you can't tell what actually executes without knowing the active aspects. Use AOP judiciously—typically for truly universal concerns (logging, transactions). Don't use it to hide business logic.

Event-Driven Approaches to Cross-Cutting

Event-driven architecture offers another approach to cross-cutting concerns: rather than wrapping business logic with additional behavior, business logic emits events that separate handlers process. This inverts control—the core code doesn't even know what cross-cutting concerns exist. The Pattern: Core business operations emit domain events. Separate event handlers (often in different modules) react to those events to implement cross-cutting behavior:

event-driven-cross-cutting.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
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
121
// Domain events
class OrderCreatedEvent {
    constructor(
        public readonly orderId: string,
        public readonly userId: string,
        public readonly items: OrderItem[],
        public readonly total: Money,
        public readonly timestamp: Date
    ) {}
}
 
class OrderCancelledEvent {
    constructor(
        public readonly orderId: string,
        public readonly reason: string,
        public readonly timestamp: Date
    ) {}
}
 
// Core service - emits events but doesn't handle cross-cutting concerns
class OrderService {
    constructor(
        private repository: OrderRepository,
        private eventBus: EventBus
    ) {}
    
    async createOrder(request: CreateOrderRequest): Promise<Order> {
        // Pure business logic
        const order = Order.create(request);
        await this.repository.save(order);
        
        // Emit event - what happens next is not this class's concern
        await this.eventBus.publish(new OrderCreatedEvent(
            order.id,
            request.userId,
            order.items,
            order.total,
            new Date()
        ));
        
        return order;
    }
}
 
// ─────────────────────────────────────────────────────────────────
 
// Cross-cutting concerns as event handlers
 
// Logging handler
@EventHandler()
class OrderLoggingHandler {
    @On(OrderCreatedEvent)
    async logOrderCreated(event: OrderCreatedEvent) {
        this.logger.info('Order created', {
            orderId: event.orderId,
            userId: event.userId,
            total: event.total.toString()
        });
    }
    
    @On(OrderCancelledEvent)
    async logOrderCancelled(event: OrderCancelledEvent) {
        this.logger.info('Order cancelled', {
            orderId: event.orderId,
            reason: event.reason
        });
    }
}
 
// Analytics handler
@EventHandler()
class OrderAnalyticsHandler {
    @On(OrderCreatedEvent)
    async trackOrderCreated(event: OrderCreatedEvent) {
        await this.analytics.track('order_created', {
            orderId: event.orderId,
            value: event.total.toNumber(),
            itemCount: event.items.length
        });
    }
}
 
// Notification handler
@EventHandler()
class OrderNotificationHandler {
    @On(OrderCreatedEvent)
    async sendConfirmation(event: OrderCreatedEvent) {
        const user = await this.userRepository.findById(event.userId);
        await this.mailer.send({
            to: user.email,
            template: 'order-confirmation',
            data: { orderId: event.orderId, total: event.total }
        });
    }
}
 
// Inventory handler
@EventHandler()
class InventoryHandler {
    @On(OrderCreatedEvent)
    async reserveInventory(event: OrderCreatedEvent) {
        for (const item of event.items) {
            await this.inventory.reserve(item.productId, item.quantity);
        }
    }
    
    @On(OrderCancelledEvent)
    async releaseInventory(event: OrderCancelledEvent) {
        const order = await this.orderRepository.findById(event.orderId);
        for (const item of order.items) {
            await this.inventory.release(item.productId, item.quantity);
        }
    }
}
 
// Benefits:
// 1. OrderService is clean - just business logic
// 2. Each handler is a single responsibility
// 3. Adding concerns doesn't modify OrderService
// 4. Handlers can fail independently (with appropriate handling)
// 5. Handlers can run asynchronously if appropriate

Event-Driven Benefits

•Complete decoupling of concerns
•Easy to add/remove handlers
•Handlers can be async
•Natural for distributed systems
•Core code stays pure
•Easy to test handlers independently

Event-Driven Limitations

•Hard to trace full behavior
•Event schema must be stable
•Handler failures need handling
•Ordering can be complex
•Not suitable for sync requirements
•Can lead to event storms

When to Use Events

Event-driven approaches work best when cross-cutting handlers can tolerate eventual consistency and potential failures. Logging, analytics, and notifications are excellent candidates. Authorization checks that must happen synchronously are not—use middleware or decorators for those.

Choosing the Right Approach

Each approach to cross-cutting concerns has its strengths. The right choice depends on your specific situation:

Cross-Cutting Concern Approach Selection
Approach	Best For	Avoid When
Decorators	Object-level wrapping, explicit composition, testability	Interface has many methods, need DRY across many types
Middleware/Pipeline	Request/response processing, HTTP concerns, ordered processing	Fine-grained method-level concerns, non-request contexts
AOP	Universal concerns, compile-time optimization, minimal code intrusion	Team unfamiliar with AOP, need explicit behavior, debugging priority
Event-Driven	Async side effects, multiple independent handlers, loose coupling	Sync requirements, ordering matters, need guaranteed execution

approach-selection.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
// DECISION FRAMEWORK for Cross-Cutting Concern Implementation
 
// Q1: Does the concern need to MODIFY the request/response?
//     YES → Middleware/Decorators
//     NO  → Could use events
 
// Q2: Must the concern execute SYNCHRONOUSLY with the operation?
//     YES → Middleware/Decorators/AOP
//     NO  → Events are a good option
 
// Q3: Does the concern apply UNIVERSALLY across many operations?
//     YES → AOP or Middleware at infrastructure level
//     NO  → Decorators for selective application
 
// Q4: Is EXPLICIT composition important for understanding/debugging?
//     YES → Decorators or Middleware (visible in composition)
//     NO  → AOP is acceptable
 
// ─────────────────────────────────────────────────────────────────
 
// Example: Implementing the same concern different ways
 
// AUTHENTICATION
// - Must be sync ✓
// - Modifies request (adds user context) ✓
// - Applies to most requests ✓
// → Best: Middleware
 
// AUDIT LOGGING
// - Can be async ✓
// - Doesn't modify response ✓
// - Applies after operations complete ✓
// → Best: Events or AOP
 
// CACHING
// - Must be sync (to return cached value) ✓
// - Modifies response (returns cached instead of fresh) ✓
// - Selective application ✓
// → Best: Decorators
 
// TRANSACTION MANAGEMENT
// - Must be sync ✓
// - Wraps around operation ✓
// - Applies to database operations universally ✓
// → Best: AOP or Decorators

Mix and Match

Real systems often combine approaches. You might use middleware for HTTP-level concerns (auth, rate limiting), decorators for service-level concerns (caching, retries), and events for post-operation concerns (notifications, analytics). Choose the right tool for each specific concern.

Cross-Cutting Concerns

The Concerns That Won't Stay Put

What Makes a Concern Cross-Cutting?

Catalog of Common Cross-Cutting Concerns

The Decorator Pattern for Cross-Cutting Concerns

Middleware and Pipeline Architectures

Aspect-Oriented Programming (AOP)

Event-Driven Approaches to Cross-Cutting

Choosing the Right Approach

There’s more to understand.

Cross-Cutting Concerns

The Concerns That Won't Stay Put

What Makes a Concern Cross-Cutting?

Catalog of Common Cross-Cutting Concerns

The Decorator Pattern for Cross-Cutting Concerns

Middleware and Pipeline Architectures

Aspect-Oriented Programming (AOP)

Event-Driven Approaches to Cross-Cutting

Choosing the Right Approach

There’s more to understand.