LLD Mindset - Learning Module

Loading content...

0/246

Identifying Responsibilities and Boundaries

The Heart of Good Design

You've learned to break systems into pieces—but decomposition alone doesn't guarantee good design. A poorly decomposed system can be just as unmaintainable as a monolith. The difference lies in responsibilities and boundaries: understanding exactly what each component should do and where its authority begins and ends.

The greatest software architects share a common skill: they can look at a complex system and see clean lines of responsibility. They know intuitively which component should handle authentication, which should manage user data, and why those concerns must never be mixed. This isn't magic—it's a learned discipline rooted in fundamental principles.

This page equips you with those principles. By the end, you'll understand how to identify responsibilities, assign them correctly, and establish boundaries that keep components focused, cohesive, and maintainable.

What You Will Learn

By the end of this page, you will master the Single Responsibility Principle (SRP), understand cohesion and coupling as measurable design qualities, learn techniques for identifying and assigning responsibilities, and recognize boundary violations before they cause damage.

The Single Responsibility Principle (SRP)

The Single Responsibility Principle is often stated as:

A class should have only one reason to change.

This formulation, from Robert C. Martin, sounds simple but has profound implications. The 'reason to change' refers to an actor—a person, role, or stakeholder whose requirements might evolve. If a class changes when marketing wants new reports AND when operations wants better performance AND when compliance wants new auditing, that class serves three masters and violates SRP.

Why 'Reason to Change' Matters:

Consider an Employee class that handles:

Calculating pay (HR/Payroll)
Generating reports (Management)
Persisting to database (IT Operations)

These are three different stakeholders with different timelines, different requirements, and different change patterns. When HR changes the bonus calculation, you risk breaking the reporting logic or the database code—not because they're related, but because they're inappropriately bundled.

srp-violation.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
// VIOLATION: Employee class has three reasons to change
class Employee {
    private name: string;
    private salary: number;
    private hoursWorked: number;
    
    // Reason 1: HR changes pay calculation rules
    calculatePay(): number {
        return this.salary + this.calculateOvertime();
    }
    
    private calculateOvertime(): number {
        const overtimeHours = Math.max(0, this.hoursWorked - 40);
        return overtimeHours * (this.salary / 40) * 1.5;
    }
    
    // Reason 2: Management changes report format/content
    generateReport(): string {
        return `
            Employee Report
            Name: ${this.name}
            Hours Worked: ${this.hoursWorked}
            Total Pay: ${this.calculatePay()}
        `;
    }
    
    // Reason 3: IT changes database schema/ORM
    saveToDatabase(db: Database): void {
        db.execute(
            'INSERT INTO employees (name, salary, hours) VALUES (?, ?, ?)',
            [this.name, this.salary, this.hoursWorked]
        );
    }
}

srp-compliant.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// SOLUTION: Separate classes for separate responsibilities
 
// Pure domain entity - changes only when the concept of Employee changes
class Employee {
    constructor(
        public readonly id: string,
        public name: string,
        public hourlyRate: number,
        public hoursWorked: number
    ) {}
}
 
// Changes when pay calculation rules change (HR stakeholder)
class PayrollCalculator {
    calculate(employee: Employee): PayStatement {
        const regularPay = Math.min(employee.hoursWorked, 40) * employee.hourlyRate;
        const overtimePay = Math.max(0, employee.hoursWorked - 40) * employee.hourlyRate * 1.5;
        return new PayStatement(employee.id, regularPay, overtimePay);
    }
}
 
// Changes when report requirements change (Management stakeholder)
class EmployeeReporter {
    generateReport(employee: Employee, payStatement: PayStatement): string {
        return `Employee: ${employee.name}, Total Pay: ${payStatement.total}`;
    }
}
 
// Changes when persistence strategy changes (IT stakeholder)
class EmployeeRepository {
    constructor(private db: Database) {}
    
    save(employee: Employee): void {
        this.db.upsert('employees', {
            id: employee.id,
            name: employee.name,
            hourlyRate: employee.hourlyRate,
            hoursWorked: employee.hoursWorked
        });
    }
}

The Actor Test

To check for SRP violations, ask: 'Who would request changes to this class?' List the actors (HR, marketing, operations, customers, etc.). If you list more than one actor, consider whether those responsibilities should be separate components. Not all separations are necessary—but you should consciously decide, not accidentally mix.

Understanding Cohesion

Cohesion measures how strongly related the elements within a component are. High cohesion means every part of the component works toward a single, focused purpose. Low cohesion means the component is a grab-bag of loosely related or unrelated functionality.

The Cohesion Spectrum:

Cohesion isn't binary—it exists on a spectrum from worst to best:

Types of Cohesion (Worst to Best)
Type	Description	Example
Coincidental (Worst)	Elements grouped arbitrarily, no relationship	`Utils` class with unrelated methods
Logical	Elements grouped by category, but different functions	`InputHandler` doing keyboard, mouse, and touchscreen
Temporal	Elements grouped because they run at the same time	`StartupInitializer` doing logging, DB, and cache setup
Procedural	Elements grouped because they follow a sequence	`CheckoutProcessor` with steps that should be separate
Communicational	Elements work on the same data	`CustomerProcessor` reading and writing customer records
Sequential	Output of one element is input to another	`DataPipeline` where each step transforms data
Functional (Best)	All elements contribute to a single, well-defined task	`PasswordHasher` that only hashes passwords

Functional Cohesion: The Goal

The ideal is functional cohesion—every method, every field, every line of code in the component contributes directly to its single purpose. Nothing is incidental.

Example of High Functional Cohesion:

A JwtTokenValidator class that:

Parses JWT tokens
Verifies signatures
Checks expiration
Returns validation result

Every method directly supports the single purpose: validating JWT tokens. Nothing else.

Example of Low Cohesion (Coincidental):

A Helpers class containing:

formatDate() for UI display
calculateDistance() for geo calculations
sendEmail() for notifications
compressImage() for media processing

These have no relationship other than 'someone needed them.' This is a red flag indicating responsibilities scattered inappropriately.

The 'Utils' Smell

When you see classes named Utils, Helpers, Common, or Misc, it's almost always a cohesion problem. These classes become dumping grounds for homeless functionality. Instead, find where each method truly belongs—or create a properly named class that owns its responsibility.

Measuring Cohesion: LCOM

Lack of Cohesion of Methods (LCOM) is a metric that counts how many method pairs in a class share no instance variables. High LCOM indicates low cohesion.

While formal metrics are useful for analyzing existing code, the more practical approach is to ask yourself:

Can I describe this class's purpose in one simple sentence?
Does every method directly support that purpose?
Would removing any method make the class incomplete?

If the answer to all three is yes, you likely have high cohesion.

Understanding Coupling

If cohesion is about internal unity, coupling is about external dependencies. Coupling measures how strongly components are connected—how much one component must know about another to function.

The Coupling Spectrum:

Like cohesion, coupling exists on a spectrum:

Types of Coupling (Worst to Best)
Type	Description	Why It's Problematic
Content (Worst)	One component directly modifies another's internals	Changes anywhere break everything
Common	Components share global state	Race conditions, hidden dependencies
External	Components share external format/protocol	External changes ripple widely
Control	One component tells another how to behave via flags	Breaks encapsulation, couples logic
Stamp/Data-Structure	Components share composite data structures	Structure changes affect all users
Data (Best)	Components share only primitive data via parameters	Minimal assumptions, maximum flexibility
Message (Best)	Components interact only via messages	Complete decoupling, async-friendly

Loose Coupling: The Goal

Ideal systems have loose coupling—components interact through well-defined interfaces, know nothing about each other's internals, and can be modified independently.

Benefits of Loose Coupling:

Changes localize to single components
Components can be tested in isolation
Components can be replaced without system-wide changes
Teams can work independently
Systems can evolve incrementally

Tight Coupling (Bad)

•Component A directly instantiates Component B
•A calls B's private/internal methods
•A knows B's implementation details
•A and B share mutable global state
•Changing B breaks A unexpectedly

Loose Coupling (Good)

•A depends on an interface, not B directly
•A calls only public, documented methods
•A knows only B's contract, not implementation
•State is encapsulated within each component
•B's internals can change without affecting A

coupling-example.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// TIGHT COUPLING: OrderService depends on concrete EmailService
class OrderService {
    private emailService: EmailService;
    
    constructor() {
        // Direct instantiation creates tight coupling
        this.emailService = new EmailService('smtp.example.com', 587, 'user', 'pass');
    }
    
    processOrder(order: Order): void {
        // Business logic...
        
        // Calling with specific EmailService assumptions
        this.emailService.connect();  // You shouldn't know this method exists
        this.emailService.sendHtml(order.customer.email, 'Order Confirmed', '...');
        this.emailService.disconnect();  // Managing connection state externally
    }
}
 
// LOOSE COUPLING: OrderService depends on abstraction
interface NotificationSender {
    send(recipient: string, message: NotificationMessage): Promise<void>;
}
 
class OrderService {
    constructor(private notifier: NotificationSender) {}
    
    async processOrder(order: Order): Promise<void> {
        // Business logic...
        
        // Simple, abstracted call - doesn't know if it's email, SMS, or push
        await this.notifier.send(
            order.customer.id,
            new OrderConfirmation(order)
        );
    }
}
 
// Now we can inject any implementation:
// new OrderService(new EmailNotifier(config))
// new OrderService(new SmsNotifier(config))
// new OrderService(new MockNotifier())  // For testing

The Balance

Zero coupling is impossible—components must interact somehow. The goal isn't eliminating coupling but minimizing unnecessary coupling and ensuring remaining connections are through stable, abstract interfaces rather than volatile implementation details.

Techniques for Assigning Responsibilities

Given a set of requirements, how do you decide which class handles what? Several established techniques help you systematically assign responsibilities.

Technique 1: GRASP Principles

General Responsibility Assignment Software Patterns (GRASP) provide nine principles for assigning responsibilities. The most foundational are:

Core GRASP Principles

•Information Expert — Assign responsibility to the class with the information needed to fulfill it. If Order contains line items, Order should calculate the total.
•Creator — Assign object creation to the class that contains, aggregates, records, or closely uses the created object. Order creates LineItem; Customer creates Order.
•Controller — Assign system event handling to a class representing the overall system or use case. CheckoutController coordinates checkout, but doesn't do checkout logic itself.
•Low Coupling — Assign responsibilities to maintain minimal dependencies. If two options exist, choose the one that reduces coupling.
•High Cohesion — Assign responsibilities to keep classes focused. If adding a method would reduce cohesion, find a better home for it.
•Polymorphism — When behavior varies by type, use polymorphism rather than conditionals. Different payment types should be different classes, not if-else chains.
•Pure Fabrication — When no domain class is appropriate, create a 'service' class. OrderRepository isn't a real domain thing but provides a necessary abstraction.
•Indirection — Add an intermediate class to decouple two others. A PaymentGateway interface decouples business logic from specific payment providers.

Technique 2: The Information Expert Pattern

This is often the most useful starting point. Ask: 'What information is needed to perform this responsibility?' Assign the responsibility to the class that holds that information.

Example: Who calculates order total?

To calculate total, you need:

Line items in the order
Price of each item
Quantities
Applicable discounts

The Order class already contains the line items. Making it the information expert for totaling makes sense—it has the data and should have the method.

information-expert.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// Information Expert: Order calculates its own total
class Order {
    private lineItems: LineItem[] = [];
    private discount?: Discount;
    
    addLineItem(product: Product, quantity: number): void {
        this.lineItems.push(new LineItem(product, quantity));
    }
    
    applyDiscount(discount: Discount): void {
        this.discount = discount;
    }
    
    // Order is the Information Expert - it has the data needed
    calculateTotal(): Money {
        const subtotal = this.lineItems.reduce(
            (sum, item) => sum.add(item.calculateSubtotal()),
            Money.zero()
        );
        
        if (this.discount) {
            return this.discount.apply(subtotal);
        }
        return subtotal;
    }
}
 
class LineItem {
    constructor(
        private product: Product,
        private quantity: number
    ) {}
    
    // LineItem is Information Expert for its own subtotal
    calculateSubtotal(): Money {
        return this.product.price.multiply(this.quantity);
    }
}

Technique 3: CRC Cards

Class-Responsibility-Collaboration (CRC) cards are a physical or conceptual tool for responsibility assignment. For each class:

Class Name: What is this thing?
Responsibilities: What does it know? What does it do?
Collaborators: What other classes does it work with?

Walking through scenarios with CRC cards helps identify missing classes, misplaced responsibilities, and excessive coupling.

Example CRC Card: ShoppingCart
Class: ShoppingCart
Responsibilities	Collaborators
Maintain list of items	CartItem
Calculate subtotal	CartItem
Apply discount codes	DiscountService
Check product availability	InventoryService
Track last modified time	(internal)

Scenario Walk-Through

After creating initial CRC cards, simulate user scenarios: 'A user adds an item to cart—which class handles it? What collaborations occur?' If the flow feels awkward or requires many collaborators for simple operations, reconsider your responsibility assignments.

Establishing Clear Boundaries

Assigning responsibilities is only half the equation. You must also establish boundaries—clear lines that separate components and define how they interact. Boundaries prevent responsibilities from leaking, coupling from creeping, and complexity from spreading.

Types of Boundaries:

Boundary Type	Mechanism	When to Use
Package/Module	Directory structure, namespace	Group related classes within a bounded context
Interface	Abstract contract	Decouple consumers from implementations
Access Modifier	Public/private/protected	Hide internals within a class
Service	Network/IPC separation	When deployment independence is needed
Database Schema	Separate tables/databases	When data ownership must be explicit

The Law of Demeter (LoD)

Also known as the 'principle of least knowledge,' the Law of Demeter states:

A method should only call methods on:

Its own object (this)

Objects passed as parameters

Objects it creates

Its direct component objects (fields)

Violating LoD creates hidden dependencies through 'train wrecks':

law-of-demeter.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// VIOLATION: 'Train wreck' - reaching through multiple objects
function getCustomerCity(order: Order): string {
    // This method knows too much about Order's internal structure
    return order.getCustomer().getAddress().getCity();
}
// If any link in the chain changes, this code breaks
 
// COMPLIANT: Ask, don't tell
class Order {
    getShippingCity(): string {
        // Order knows how to get its shipping city
        // Caller doesn't need to know about Customer or Address
        return this.customer.getShippingCity();
    }
}
 
class Customer {
    getShippingCity(): string {
        return this.shippingAddress.getCity();
    }
}
 
// Now the call is simple and encapsulated
function getOrderCity(order: Order): string {
    return order.getShippingCity();  // One level, clear boundary
}

Tell, Don't Ask

A related principle: instead of asking objects for data and then acting on it, tell objects what to do and let them act.

Ask (Bad):

if (user.getPermissions().contains('ADMIN')) {
    // perform admin action
}

Tell (Good):

user.performAdminAction(action);  // Let User check its own permissions

This keeps logic with the data, maintains boundaries, and prevents knowledge from leaking across components.

Boundaries at Every Level

Boundaries aren't just between services. Within a single class, private methods establish boundaries. Within a module, internal classes are bounded. Think of boundaries at every level of abstraction—they all serve the same purpose: encapsulating change and limiting knowledge.

Recognizing Boundary Violations

Boundaries erode over time as developers add 'quick fixes' and 'temporary workarounds.' Learning to spot boundary violations is essential for maintaining system integrity.

Common Boundary Violation Patterns

•Feature Envy — A method uses more features of another class than its own. It 'envies' the other class and probably belongs there.
•Inappropriate Intimacy — Two classes are too familiar with each other's internals, exchanging private details that should be hidden.
•Shotgun Surgery — Making a single change requires modifying many classes. Responsibilities are too scattered.
•Parallel Inheritance — Every time you add a subclass to one hierarchy, you must add one to another. The hierarchies are coupled.
•Leaky Abstraction — Implementation details bleed through the interface. Users must understand internals to use the component correctly.
•Circular Dependencies — A depends on B, which depends on C, which depends on A. Boundaries are unclear.

Feature Envy in Practice:

feature-envy.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
// FEATURE ENVY: ReportGenerator uses Customer's data more than its own
class ReportGenerator {
    generateCustomerSummary(customer: Customer): string {
        // This method 'envies' Customer - it knows all about Customer internals
        const totalSpent = customer.orders
            .map(o => o.total)
            .reduce((a, b) => a + b, 0);
        const avgOrder = totalSpent / customer.orders.length;
        const loyaltyLevel = totalSpent > 10000 ? 'Gold' : totalSpent > 1000 ? 'Silver' : 'Bronze';
        
        return `Customer: ${customer.name}, Spent: ${totalSpent}, Avg: ${avgOrder}, Level: ${loyaltyLevel}`;
    }
}
 
// SOLUTION: Move behavior to where the data is
class Customer {
    getTotalSpent(): number {
        return this.orders.reduce((sum, order) => sum + order.total, 0);
    }
    
    getAverageOrderValue(): number {
        return this.getTotalSpent() / this.orders.length;
    }
    
    getLoyaltyLevel(): LoyaltyLevel {
        const total = this.getTotalSpent();
        if (total > 10000) return LoyaltyLevel.Gold;
        if (total > 1000) return LoyaltyLevel.Silver;
        return LoyaltyLevel.Bronze;
    }
    
    getSummary(): CustomerSummary {
        return {
            name: this.name,
            totalSpent: this.getTotalSpent(),
            averageOrder: this.getAverageOrderValue(),
            loyaltyLevel: this.getLoyaltyLevel()
        };
    }
}
 
class ReportGenerator {
    generateCustomerSummary(customer: Customer): string {
        const summary = customer.getSummary();  // Ask for summary, don't compute it
        return `Customer: ${summary.name}, Level: ${summary.loyaltyLevel}`;
    }
}

Violations Compound

Each boundary violation makes the next one easier. 'We already reach through Customer to get Orders, why not also reach through Order to get LineItems?' Soon the entire system is a tangled web. Catch violations early and refactor immediately.

Practical Boundary Design

Let's apply these principles to a practical example: designing boundaries for an e-commerce checkout system.

The Scenario:

Checkout must:

Validate cart contents
Apply pricing rules and discounts
Calculate shipping
Process payment
Create order record
Send confirmation
Update inventory

Naive Approach (Poor Boundaries):

A single CheckoutService doing everything. It knows about carts, pricing, shipping tables, payment APIs, order schemas, email templates, and inventory databases.

poor-boundaries.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
// POOR BOUNDARIES: Monolithic service
class CheckoutService {
    constructor(
        private cartDb: CartDatabase,
        private productDb: ProductDatabase,
        private pricingRules: PricingRulesEngine,
        private shippingTables: ShippingRates,
        private paymentGateway: StripeAPI,
        private orderDb: OrderDatabase,
        private emailClient: SendgridClient,
        private inventoryDb: InventoryDatabase
    ) {}
    
    // 500 lines of checkout logic mixing all concerns...
    async checkout(userId: string): Promise<Order> {
        // Cart validation logic
        // Pricing calculation logic
        // Shipping rate lookup
        // Payment processing logic
        // Order creation logic
        // Email sending logic
        // Inventory update logic
        // All intertwined with shared local variables
    }
}

Better Approach (Clear Boundaries):

Separate services with clear interfaces and responsibilities:

good-boundaries.ts
TypeScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
// GOOD BOUNDARIES: Separated concerns with clear interfaces
 
// Each service has a single responsibility and clear interface
interface CartService {
    getCart(userId: string): Cart;
    validateCart(cart: Cart): ValidationResult;
    clearCart(userId: string): void;
}
 
interface PricingService {
    calculatePrice(cart: Cart): PricedCart;
    applyDiscounts(pricedCart: PricedCart, codes: string[]): PricedCart;
}
 
interface ShippingService {
    calculateShipping(cart: Cart, address: Address): ShippingQuote;
    getDeliveryEstimate(quote: ShippingQuote): DateRange;
}
 
interface PaymentService {
    authorize(amount: Money, method: PaymentMethod): AuthorizationResult;
    capture(authorization: Authorization): CaptureResult;
}
 
interface OrderService {
    createOrder(checkout: CheckoutData): Order;
    getOrder(orderId: string): Order;
}
 
interface NotificationService {
    sendOrderConfirmation(order: Order): Promise<void>;
}
 
interface InventoryService {
    reserve(items: OrderItem[]): ReservationResult;
    commit(reservationId: string): void;
    release(reservationId: string): void;
}
 
// CheckoutOrchestrator coordinates - it knows WHAT to do, not HOW
class CheckoutOrchestrator {
    constructor(
        private cart: CartService,
        private pricing: PricingService,
        private shipping: ShippingService,
        private payment: PaymentService,
        private orders: OrderService,
        private notifications: NotificationService,
        private inventory: InventoryService
    ) {}
    
    async checkout(userId: string, paymentMethod: PaymentMethod): Promise<Order> {
        // Each step is delegated to the responsible service
        const cart = this.cart.getCart(userId);
        const validation = this.cart.validateCart(cart);
        if (!validation.isValid) throw new ValidationError(validation.errors);
        
        const pricedCart = this.pricing.calculatePrice(cart);
        const shippingQuote = this.shipping.calculateShipping(cart, cart.shippingAddress);
        
        const reservation = await this.inventory.reserve(cart.items);
        try {
            const auth = await this.payment.authorize(pricedCart.total, paymentMethod);
            const order = await this.orders.createOrder({ pricedCart, shippingQuote, auth });
            
            await this.payment.capture(auth);
            await this.inventory.commit(reservation.id);
            await this.notifications.sendOrderConfirmation(order);
            
            this.cart.clearCart(userId);
            return order;
        } catch (error) {
            this.inventory.release(reservation.id);
            throw error;
        }
    }
}

Benefits of Clear Boundaries

With clear boundaries: pricing rules can change without touching checkout flow, payment provider can be swapped by implementing a new adapter, each service can be tested independently, teams can own different services, and failures are isolated to specific domains.

Summary: Responsibilities and Boundaries

We've covered the essential principles for identifying responsibilities and establishing boundaries. Let's consolidate the key lessons:

Key Takeaways

•Single Responsibility Principle — Each component should have one reason to change, corresponding to one stakeholder or category of requirement.
•High Cohesion — Elements within a component should be strongly related, all contributing to a single, clear purpose. Aim for functional cohesion.
•Low Coupling — Dependencies between components should be minimal and through stable interfaces, not volatile implementation details.
•Use GRASP Principles — Information Expert, Creator, Controller, and other GRASP patterns provide systematic guidance for assigning responsibilities.
•Enforce Boundaries — Use the Law of Demeter and 'Tell, Don't Ask' to maintain clean boundaries between components.
•Recognize Violations — Feature envy, inappropriate intimacy, and shotgun surgery are warning signs that responsibilities and boundaries are misaligned.

What's Next:

With clear responsibilities and boundaries established, the next challenge is understanding how components interact. Before implementing any code, experienced designers think through interactions—the messages passed, the sequences of calls, the failure modes. That's the topic of our next page.

Page Complete

You now understand how to identify and assign responsibilities to components, and how to establish clear boundaries that enable loose coupling and high cohesion. These principles are the bedrock of maintainable design. Next, we'll explore how to think about component interactions before rushing to implementation.