Cohesion & Coupling - Learning Module

Loading content...

0/246

Trade-offs in Design

The Art of Imperfect Choices

If software design were a matter of always maximizing cohesion and minimizing coupling, it would be a simple, mechanical exercise—apply the rules, measure the results, ship the code. But experienced engineers know that design is rarely so straightforward.

In practice, high cohesion can conflict with reusability. Reducing coupling might introduce its own complexity. Perfecting one module might degrade another. Achieving ideal metrics today might hinder evolution tomorrow. And sometimes, the 'right' architectural choice is simply too expensive given business constraints.

Trade-offs are the essence of engineering. Not trade-offs born of laziness or ignorance, but conscious, informed decisions about which qualities to optimize and which to sacrifice. The mark of senior engineers is not that they always make the 'correct' choice, but that they understand the consequences of their choices.

What You Will Learn

This page explores the tensions inherent in cohesion and coupling decisions. You will learn common trade-off scenarios, frameworks for navigating competing concerns, context-dependent decision making, and strategies for living with imperfect choices.

Cohesion vs. Reusability

High cohesion suggests that a module should do one thing well. Reusability suggests that a module should be applicable in many contexts. These goals can conflict.

The tension:

A highly cohesive module is focused on a specific purpose, with behavior tailored to that purpose. But a reusable module needs to be general enough to work in multiple contexts—often requiring configuration, hooks, or abstractions that dilute focus.

Consider a CustomerEmailer class: highly cohesive, specifically designed for emailing customers with company branding and templates. Vs. a generic Emailer class: more reusable (can email anyone with any template), but less cohesive (must handle many unrelated emailing scenarios).

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
class CustomerWelcomeEmailer {
  constructor(
    private branding: BrandingConfig,
    private templates: CustomerTemplates
  ) {}
  
  // Extremely focused
  sendWelcome(customer: Customer): void {
    const email = this.templates.welcome(
      customer.name,
      this.branding
    );
    this.send(customer.email, email);
  }
  
  // Only these use cases
  sendPasswordReset(customer: Customer): void {
    // ...
  }
  
  sendPurchaseConfirmation(
    customer: Customer, 
    order: Order
  ): void {
    // ...
  }
  
  // Cannot email non-customers
  // Cannot use arbitrary templates
  // Cannot send marketing emails
}

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
class GenericEmailer {
  // Can send any email to anyone
  send(
    to: string,
    subject: string,
    body: string,
    options?: EmailOptions
  ): void { }
  
  // Supports templates
  sendFromTemplate(
    to: string,
    template: Template,
    data: Record<string, any>
  ): void { }
  
  // Supports batching
  sendBatch(
    recipients: string[],
    template: Template,
    data: Record<string, any>[]
  ): void { }
  
  // Supports scheduling
  schedule(
    email: EmailConfig,
    sendAt: Date
  ): void { }
  
  // Generic enough for any use
  // But now handles many concerns
}

Navigating this trade-off:

Ask who will reuse this. If the answer is 'only this team' or 'only this application,' optimize for cohesion. Generalization for hypothetical reuse is waste.
Layer your abstraction. Create a generic, reusable core (Emailer) and cohesive domain-specific wrappers (CustomerWelcomeEmailer extends Emailer). The core handles mechanics; wrappers add domain cohesion.
Accept duplication sometimes. If making something reusable would dilute focus significantly, it may be better to have two focused implementations than one confused one. DRY is about knowledge, not code.
Design for extension. Even cohesive modules can be reusable if designed for extension. Allow behavior injection through interfaces rather than embedding all variations.

The Rule of Three

Don't generalize preemptively. The first time you need a capability, implement it specifically. The second time, note the duplication but don't act. The third time, consider extraction into a reusable module. By then you have three examples to understand the true abstraction.

Low Coupling vs. Performance

Reducing coupling often means introducing indirection—interfaces, adapters, event buses, message queues. But indirection has performance costs. Sometimes, tight coupling enables optimizations that loose coupling prevents.

The tension:

Decoupled systems communicate through abstractions. Each abstraction layer adds latency (function calls, serialization, network hops). In performance-critical paths, this overhead can be prohibitive.

Consider a high-frequency trading system processing millions of transactions per second. The beautifully decoupled, event-driven architecture that works for an e-commerce site might add unacceptable microseconds of latency. Here, tightly coupled, cache-optimized code paths become necessary.

Coupling Reduction Techniques and Their Performance Costs
Technique	Decoupling Benefit	Performance Cost
Interface abstraction	Implementation substitutability	Virtual dispatch overhead (minimal)
Dependency injection	Configurable, testable dependencies	Object creation, potential allocation
Event-driven communication	Publisher/subscriber independence	Event serialization, routing overhead
Message queues	Temporal decoupling, buffering	Network I/O, serialization, latency
Microservices	Independent deployment/scaling	Network calls, distributed overhead
API gateways	Centralized cross-cutting concerns	Additional network hop, processing

Navigating this trade-off:

Profile before optimizing. Don't sacrifice decoupling for hypothetical performance gains. Measure actual bottlenecks. Often, the indirection cost is negligible compared to I/O or computation.
Differentiate hot and cold paths. Most applications have a small percentage of code that's performance critical (hot paths) and the majority that isn't (cold paths). Decouple cold paths liberally; optimize hot paths surgically.
Use zero-cost abstractions where available. Modern compilers often inline interfaces, devirtualize calls, and eliminate abstraction overhead. What looks like indirection in source code may compile to direct calls.
Accept coupling in the inner loop. For genuinely hot paths, it's acceptable to violate coupling guidelines. Document why, isolate the coupled code, and ensure the coupling doesn't leak beyond the critical section.
Consider batch optimizations. Sometimes you can maintain decoupling at the API level while adding batch operations that amortize overhead across many items.

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
// Public interface maintains decoupling
interface OrderProcessor {
    process(order: Order): ProcessingResult;
    processBatch(orders: Order[]): ProcessingResult[];
}
 
// Standard implementation: fully decoupled
class StandardOrderProcessor implements OrderProcessor {
    constructor(
        private validator: OrderValidator,
        private pricer: OrderPricer,
        private fulfillment: FulfillmentService
    ) {}
    
    process(order: Order): ProcessingResult {
        const valid = this.validator.validate(order);
        const priced = this.pricer.price(order);
        return this.fulfillment.fulfill(priced);
    }
    
    processBatch(orders: Order[]): ProcessingResult[] {
        return orders.map(o => this.process(o));
    }
}
 
// High-performance implementation: tightly coupled internals
class HighPerformanceOrderProcessor implements OrderProcessor {
    // No injected dependencies—inlined for performance
    private cache: PriceCache;
    private inventorySnapshot: InventorySnapshot;
    
    process(order: Order): ProcessingResult {
        // Tightly coupled, cache-optimized hot path
        // Deliberately violates DIP for nanosecond gains
        const price = this.cache.getOrCompute(order.sku);
        const available = this.inventorySnapshot.check(order.sku);
        return this.processInternal(order, price, available);
    }
    
    processBatch(orders: Order[]): ProcessingResult[] {
        // Even more optimized: prefetch, vectorize, batch I/O
        this.prefetchPrices(orders);
        this.prefetchInventory(orders);
        return this.processBatchOptimized(orders);
    }
}
 
// The system chooses implementation based on context
const processor = isHighThroughputMode()
    ? new HighPerformanceOrderProcessor()
    : new StandardOrderProcessor(validator, pricer, fulfillment);

Premature Optimization Danger

The vast majority of coupling 'for performance' is premature optimization. Before adding coupling for speed, verify: (1) This code is actually on the hot path, (2) The abstraction overhead is measurable and significant, (3) You've tried optimization that preserves decoupling first.

Granularity Tensions: Too Much vs. Too Little

Both cohesion and coupling improvements can be taken too far. Excessively fine-grained modules can be as problematic as overly coarse ones. There's a 'Goldilocks zone' for granularity.

The tension:

High cohesion suggests splitting large classes into smaller, focused ones. But taken to extreme, you get dozens of tiny classes that individually are cohesive but collectively are hard to understand—each class so small that the system's logic is smeared across many files.

Low coupling suggests minimizing dependencies. But taken to extreme, you get isolated modules that duplicate logic rather than share it, or communication mechanisms so abstract that following data flow becomes nearly impossible.

Too Coarse (Under-modularized)

•God classes doing everything
•Hard to test individual behaviors
•Changes affect unrelated features
•Hard to find specific functionality
•Teams step on each other
•All-or-nothing deployment

Too Fine (Over-modularized)

•Ravioli code: tiny, scattered pieces
•Hard to understand overall flow
•High coordination overhead
•Duplicated concepts across modules
•Death by abstraction layers
•Simple change requires many files

Finding the right granularity:

Team size heuristic. A module should be small enough that one person can understand it, but large enough that it encapsulates a meaningful concept. If you need a team meeting to explain a simple service, it's too fragmented.
Change frequency alignment. Code that changes together should live together. If every feature request touches 15 files, your modules are too fine. If a one-line bug fix requires understanding 2000 lines of context, too coarse.
Domain concept alignment. Modules should map to domain concepts. If 'Order' is one concept in business terms, having 50 classes each holding one tiny piece of Order logic may be over-decomposition.
Cognitive chunk size. Research suggests 7±2 items in working memory. A module with 3-10 public methods, a package with 3-10 modules, a service with 3-10 endpoints—these match human cognition.
The 'explain it' test. Can you explain what a module does to a new team member in 2-3 minutes? Too long → too big. Need to explain many modules for basic understanding → too fragmented.

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
// ❌ TOO COARSE: One class does everything
class OrderManager {
    createOrder() { } 
    validateOrder() { }
    calculateTax() { }
    calculateShipping() { }
    processPayment() { }
    sendConfirmation() { }
    generateInvoice() { }
    updateInventory() { }
    notifyWarehouse() { }
    trackShipment() { }
    handleReturns() { }
    // ... 50 more methods
}
 
// ❌ TOO FINE: Class-per-operation explosion
class OrderCreator { }
class OrderValidator { }
class OrderTaxCalculator { }
class OrderShippingCalculator { }
class OrderPaymentProcessor { }
class OrderConfirmationSender { }
class OrderInvoiceGenerator { }
class InventoryUpdater { }
class WarehouseNotifier { }
class ShipmentTracker { }
class ReturnHandler { }
// 50+ tiny classes for one bounded context
 
// ✅ BALANCED: Grouped by subdomain/responsibility
class OrderService {
    // Order lifecycle — cohesive concern
    create(items: Item[], customer: Customer): Order { }
    cancel(orderId: string): void { }
    modify(orderId: string, changes: OrderChanges): Order { }
}
 
class OrderPricingService {
    // Pricing calculations — related concern  
    calculateSubtotal(order: Order): Money { }
    calculateTax(order: Order): Money { }
    calculateShipping(order: Order): Money { }
    calculateTotal(order: Order): Money { }
}
 
class OrderFulfillmentService {
    // Fulfillment operations — related concern
    reserve(order: Order): Reservation { }
    ship(order: Order): Shipment { }
    track(orderId: string): TrackingInfo { }
}
 
class OrderNotificationService {
    // Communications — related concern
    sendConfirmation(order: Order): void { }
    sendShippingUpdate(order: Order, status: Status): void { }
    sendDeliveryConfirmation(order: Order): void { }
}

Granularity Evolves

The right granularity changes as systems evolve. A small system might have one OrderService. As complexity grows, it splits. As team grows, it may split further into separate services. There's no permanent answer—adjust granularity as context demands.

Intentional Coupling: Shared Understanding

Not all coupling is bad. Some coupling reflects genuine coordination requirements. Trying to eliminate it can create worse problems—hidden dependencies, inconsistent behavior, or duplicated logic.

Types of intentional coupling:

Contract coupling: Services share API contracts. This coupling is intentional—it defines the agreement between them. Trying to eliminate it creates ambiguity.
Domain model coupling: Bounded contexts share certain concepts (Customer ID, Product SKU). This coupling reflects business reality—these identifiers must match across systems.
Transactional coupling: Some operations genuinely require consistency across modules. A money transfer between accounts must either complete fully or not at all.
Consistency coupling: Multiple systems display the same data. They're coupled to a consistency requirement—users expect the same information everywhere.

When trying to decouple creates problems:

Consider a system where Order Service and Inventory Service must agree on whether an order can be fulfilled. You could:

Option A: Tight coupling (synchronous call)

Order Service calls Inventory Service before confirming order
Coupled, but always consistent
If Inventory is down, orders fail

Option B: Loose coupling (eventual consistency)

Order Service publishes event
Inventory Service eventually processes it
Decoupled, but may accept unfulfillable orders
Requires compensation logic for conflicts

Option C: Distributed transaction

Two-phase commit across services
Still coupled, plus complex failure modes
Often worst of both worlds

None of these is universally superior. The right choice depends on business requirements—can you tolerate occasional inconsistency? How critical is availability? What's the compensation cost?

Guidelines for Intentional Coupling

•Make it explicit. If coupling is intentional, document it. Don't hide dependencies—surface them in architecture diagrams, API contracts, and ADRs (Architecture Decision Records).
•Couple on stable abstractions. If you must couple, couple to things unlikely to change. IDs, domain events, and core entity names are more stable than implementation details.
•Centralize shared definitions. If multiple services need the same event schema, maintain it in a shared schema registry. Coupling to a single source of truth is better than drifting duplicates.
•Accept coupling within boundaries. Inside a bounded context, coupling is expected. Objects within the same aggregate can be tightly coupled. Reserve decoupling effort for cross-boundary communication.
•Distinguish data coupling from structural coupling. Sharing data formats (data coupling) is often acceptable. Sharing internal structures (structural coupling) is not.

The Tight/Loose Spectrum Within a System

Most real systems have both tightly and loosely coupled regions. Core domain objects are tightly coupled (they must be—they model a coherent domain). Cross-domain integration is loosely coupled. Recognize that different parts of your system can and should have different coupling characteristics.

Time, Budget, and Reality

In theory, every system should be perfectly designed. In practice, there are deadlines, budgets, skill constraints, and competing priorities. Sometimes the 'right' architectural choice is unaffordable, and the 'wrong' choice is necessary.

The tension:

Refactoring for cohesion takes time. Introducing abstractions for decoupling takes time. Writing comprehensive tests that enable safe refactoring takes time. And time is finite.

A startup with runway of six months might reasonably accept architectural debt that a large enterprise shouldn't. A proof-of-concept that might be thrown away doesn't warrant the investment of production code. A team without experience in event-driven architecture shouldn't adopt it mid-crisis.

Context Factors Affecting Cohesion/Coupling Investment
Factor	Invest More In Quality	Accept More Shortcuts
Lifespan	Long-lived production system	Short-term PoC or spike
Scale	High-traffic, high-criticality	Internal tool, few users
Team size	Large team, multiple squads	Solo developer, small team
Change rate	Rapidly evolving requirements	Stable, well-understood domain
Hiring	Expect team turnover/growth	Stable, long-tenured team
Risk	Failure has high cost	Failure is recoverable

Strategies for constrained situations:

Strategic debt. Accept debt consciously and track it. Document what compromises you made and why. Create tickets for remediation. This prevents 'forgotten' tech debt that compounds silently.
Incremental improvement. You don't have to fix everything at once. Improve cohesion as you touch files. Reduce coupling one module at a time. The Boy Scout Rule: leave code better than you found it.
Pay down debt with interest. When you do have time for refactoring, prioritize debt that's 'charging interest'—code that's frequently modified, causing bugs, or blocking new features.
Build scaffolding. Even if you can't refactor immediately, you can add tests, add documentation, and add interfaces that enable future refactoring.
Negotiate scope, not quality. When pressed for time, negotiate delivering fewer features to a higher standard rather than many features to a low standard. Technical debt slows future features.

The Trap of 'We'll Fix It Later'

'Later' often never comes. Each shortcut adds another item to the backlog that competes with new features. Be honest: if you don't have time to do it right now, will you really have time to do it twice later? Accept shortcuts strategically for genuinely ephemeral code, but be skeptical of debt for production systems.

Team and Organization Factors

Architecture doesn't exist in a vacuum—it's implemented by people organized into teams. Conway's Law observes that system structure tends to mirror organization structure. Cohesion and coupling decisions should account for how teams work.

Conway's Law:

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

If two teams rarely communicate, the modules they own will likely be loosely coupled (or suffer from uncoordinated tight coupling that breaks regularly). If five people share one codebase, internal boundaries matter less than if five teams share it.

Organizational Factors in Design Decisions

•Team boundaries → Module boundaries. Code owned by different teams should be loosely coupled. Teams can't coordinate on every change, so their code shouldn't require it. Apply the 'inverse Conway maneuver': structure teams to match desired architecture.
•Expertise distribution. If only one person understands a module, high internal cohesion matters less (they hold the context). But what happens when they leave? For knowledge resilience, cohesion aids onboarding.
•Communication costs. Cross-team coupling requires cross-team communication. Every dependency = potential meeting, delay, misunderstanding. Minimize dependencies across team boundaries.
•Deployment independence. Teams want to deploy their changes without coordinating with others. Coupling blocks independent deployment, creating calendar tetris and release bottlenecks.
•Ownership clarity. Who fixes bugs in tightly coupled code? If coupling crosses teams, ownership disputes arise. Clear boundaries enable clear ownership.

Example: Microservices and teams

Microservices architecture isn't just a technical pattern—it's an organizational pattern. Each service is (ideally) owned by one team that can develop, deploy, and operate it independently.

But if you have 3 developers and 30 microservices, you don't have independent teams—you have one team with a distributed monolith's operational complexity. The architecture/organization mismatch creates pain.

Conversely, if you have 300 developers sharing one monolith, even high internal cohesion doesn't prevent bottlenecks—everyone's working in the same repo, same deploy pipeline, same codebase.

The lesson: Match architectural boundaries to organizational boundaries. Don't adopt microservices because they're trendy; adopt them when you have the teams to own them. Don't maintain a monolith when team size demands independence.

The Inverse Conway Maneuver

If your current architecture doesn't serve you, consider reorganizing teams to produce the architecture you want. Want more decoupled services? Create teams around those services. Want a more cohesive platform? Create a platform team. Structure the organization, and the architecture will follow.

Evolution Over Perfection

Perhaps the most important trade-off mindset: design for change, not for perfection. The best architecture is not the one that's perfectly optimal today, but the one that can evolve gracefully as requirements shift.

The tension:

Designing for the known requirements of today is relatively straightforward. Designing for unknown requirements of tomorrow is harder—you must make guesses, which may be wrong. But designing to easily change your guesses later is achievable.

Principles for evolutionary architecture:

Defer decisions. Don't lock in choices that can be deferred. Use interfaces to defer implementation choice. Use feature flags to defer feature decisions. Use A/B tests to defer UX decisions. Late binding preserves options.
Make decisions reversible. When you must decide, choose options that are easy to reverse. A database migration is hard to reverse; an abstraction layer in front of it can be swapped. Prefer reversible over 'optimal but irreversible.'
Run experiments. Unsure about an architectural choice? Prototype alternatives. Build a thin slice with Option A and Option B. See which works better in practice before committing.
Build seams. Even if you don't currently need to replace a component, design the seam where replacement would happen. The interface might never be re-implemented, but its existence clarifies boundaries.
Accept impermanence. Today's brilliant design will be tomorrow's legacy code. Don't optimize for a future that may never arrive. Build for now, enable change later.

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
// Today: Simple in-memory implementation
// Tomorrow: Could be Redis, could be database, could be external service
// The seam enables change without rewriting consumers
 
interface FeatureFlags {
    isEnabled(flag: string): boolean;
    getVariant(flag: string): string | null;
}
 
// Current implementation: simple config file
class ConfigFileFeatureFlags implements FeatureFlags {
    private config: Record<string, boolean | string>;
    
    constructor(configPath: string) {
        this.config = JSON.parse(fs.readFileSync(configPath, 'utf-8'));
    }
    
    isEnabled(flag: string): boolean {
        return this.config[flag] === true;
    }
    
    getVariant(flag: string): string | null {
        const value = this.config[flag];
        return typeof value === 'string' ? value : null;
    }
}
 
// Future: When we need dynamic flags, experimentation, A/B testing
class LaunchDarklyFeatureFlags implements FeatureFlags {
    constructor(private client: LaunchDarklyClient, private user: User) {}
    
    isEnabled(flag: string): boolean {
        return this.client.variation(flag, this.user, false);
    }
    
    getVariant(flag: string): string | null {
        return this.client.variation(flag, this.user, null);
    }
}
 
// Application code doesn't know or care which implementation
// Switching is a configuration change, not a code change
class CheckoutFlow {
    constructor(private flags: FeatureFlags) {}
    
    checkout(cart: Cart): void {
        if (this.flags.isEnabled('new-checkout-ui')) {
            this.renderNewCheckout(cart);
        } else {
            this.renderLegacyCheckout(cart);
        }
    }
}

The 'Last Responsible Moment'

Lean software development advocates deciding at the 'last responsible moment'—the latest point at which a decision can be made without losing options. This doesn't mean procrastination; it means gathering information before committing. The longer you wait (within reason), the more you know, the better your decision.

Summary: Living with Trade-offs

We've explored the tensions and trade-offs inherent in cohesion and coupling decisions. Let's consolidate the key insights as guiding principles:

Key Trade-off Principles

•Cohesion and reusability conflict — Highly focused modules are less generic; layer specific wrappers over reusable cores.
•Decoupling has performance costs — Profile before assuming overhead matters; accept coupling in hot paths when truly necessary.
•Both over- and under-modularization hurt — Find the Goldilocks zone where modules are comprehensible units, not too large, not too fragmented.
•Some coupling is intentional — Shared contracts, domain identifiers, and consistency requirements are valid coupling; make them explicit.
•Constraints are real — Time, budget, skills, and team structure affect viable options; accept strategic debt when necessary.
•Architecture mirrors organization — Align module boundaries with team boundaries; use Conway's Law intentionally.
•Evolution trumps perfection — Design for change, defer decisions, build seams, accept impermanence.

Closing reflection:

Cohesion and coupling are not ends in themselves—they serve the larger goal of building systems that can be understood, changed, and operated effectively. When cohesion or coupling decisions conflict with this larger goal, the larger goal wins.

The best engineers don't rigidly apply rules; they understand principles deeply enough to know when to bend them. They recognize that every design decision is a trade-off, every architecture is a compromise, and every system is a work in progress.

Your role is not to build perfect systems. Your role is to build systems that serve their purpose today and can evolve to serve tomorrow's purpose. Cohesion and coupling are tools toward that end—powerful tools, but tools nonetheless.

Module Complete

Congratulations! You have completed the Cohesion and Coupling module. You now understand high cohesion as the principle of keeping related things together, low coupling as the principle of minimizing dependencies, metrics and heuristics for measurement, and the inevitable trade-offs in real-world design. Apply these concepts as guiding principles, not rigid rules.

Trade-offs in Design

The Art of Imperfect Choices

What You Will Learn

Cohesion vs. Reusability

High cohesion suggests that a module should do one thing well. Reusability suggests that a module should be applicable in many contexts. These goals can conflict.

The tension:

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
class CustomerWelcomeEmailer {
  constructor(
    private branding: BrandingConfig,
    private templates: CustomerTemplates
  ) {}
  
  // Extremely focused
  sendWelcome(customer: Customer): void {
    const email = this.templates.welcome(
      customer.name,
      this.branding
    );
    this.send(customer.email, email);
  }
  
  // Only these use cases
  sendPasswordReset(customer: Customer): void {
    // ...
  }
  
  sendPurchaseConfirmation(
    customer: Customer, 
    order: Order
  ): void {
    // ...
  }
  
  // Cannot email non-customers
  // Cannot use arbitrary templates
  // Cannot send marketing emails
}

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
class GenericEmailer {
  // Can send any email to anyone
  send(
    to: string,
    subject: string,
    body: string,
    options?: EmailOptions
  ): void { }
  
  // Supports templates
  sendFromTemplate(
    to: string,
    template: Template,
    data: Record<string, any>
  ): void { }
  
  // Supports batching
  sendBatch(
    recipients: string[],
    template: Template,
    data: Record<string, any>[]
  ): void { }
  
  // Supports scheduling
  schedule(
    email: EmailConfig,
    sendAt: Date
  ): void { }
  
  // Generic enough for any use
  // But now handles many concerns
}

Navigating this trade-off:

Ask who will reuse this. If the answer is 'only this team' or 'only this application,' optimize for cohesion. Generalization for hypothetical reuse is waste.
Layer your abstraction. Create a generic, reusable core (Emailer) and cohesive domain-specific wrappers (CustomerWelcomeEmailer extends Emailer). The core handles mechanics; wrappers add domain cohesion.
Accept duplication sometimes. If making something reusable would dilute focus significantly, it may be better to have two focused implementations than one confused one. DRY is about knowledge, not code.
Design for extension. Even cohesive modules can be reusable if designed for extension. Allow behavior injection through interfaces rather than embedding all variations.

The Rule of Three

Low Coupling vs. Performance

The tension:

Decoupled systems communicate through abstractions. Each abstraction layer adds latency (function calls, serialization, network hops). In performance-critical paths, this overhead can be prohibitive.

Coupling Reduction Techniques and Their Performance Costs
Technique	Decoupling Benefit	Performance Cost
Interface abstraction	Implementation substitutability	Virtual dispatch overhead (minimal)
Dependency injection	Configurable, testable dependencies	Object creation, potential allocation
Event-driven communication	Publisher/subscriber independence	Event serialization, routing overhead
Message queues	Temporal decoupling, buffering	Network I/O, serialization, latency
Microservices	Independent deployment/scaling	Network calls, distributed overhead
API gateways	Centralized cross-cutting concerns	Additional network hop, processing

Navigating this trade-off:

Profile before optimizing. Don't sacrifice decoupling for hypothetical performance gains. Measure actual bottlenecks. Often, the indirection cost is negligible compared to I/O or computation.
Differentiate hot and cold paths. Most applications have a small percentage of code that's performance critical (hot paths) and the majority that isn't (cold paths). Decouple cold paths liberally; optimize hot paths surgically.
Use zero-cost abstractions where available. Modern compilers often inline interfaces, devirtualize calls, and eliminate abstraction overhead. What looks like indirection in source code may compile to direct calls.
Accept coupling in the inner loop. For genuinely hot paths, it's acceptable to violate coupling guidelines. Document why, isolate the coupled code, and ensure the coupling doesn't leak beyond the critical section.
Consider batch optimizations. Sometimes you can maintain decoupling at the API level while adding batch operations that amortize overhead across many items.

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
// Public interface maintains decoupling
interface OrderProcessor {
    process(order: Order): ProcessingResult;
    processBatch(orders: Order[]): ProcessingResult[];
}
 
// Standard implementation: fully decoupled
class StandardOrderProcessor implements OrderProcessor {
    constructor(
        private validator: OrderValidator,
        private pricer: OrderPricer,
        private fulfillment: FulfillmentService
    ) {}
    
    process(order: Order): ProcessingResult {
        const valid = this.validator.validate(order);
        const priced = this.pricer.price(order);
        return this.fulfillment.fulfill(priced);
    }
    
    processBatch(orders: Order[]): ProcessingResult[] {
        return orders.map(o => this.process(o));
    }
}
 
// High-performance implementation: tightly coupled internals
class HighPerformanceOrderProcessor implements OrderProcessor {
    // No injected dependencies—inlined for performance
    private cache: PriceCache;
    private inventorySnapshot: InventorySnapshot;
    
    process(order: Order): ProcessingResult {
        // Tightly coupled, cache-optimized hot path
        // Deliberately violates DIP for nanosecond gains
        const price = this.cache.getOrCompute(order.sku);
        const available = this.inventorySnapshot.check(order.sku);
        return this.processInternal(order, price, available);
    }
    
    processBatch(orders: Order[]): ProcessingResult[] {
        // Even more optimized: prefetch, vectorize, batch I/O
        this.prefetchPrices(orders);
        this.prefetchInventory(orders);
        return this.processBatchOptimized(orders);
    }
}
 
// The system chooses implementation based on context
const processor = isHighThroughputMode()
    ? new HighPerformanceOrderProcessor()
    : new StandardOrderProcessor(validator, pricer, fulfillment);

Premature Optimization Danger

Granularity Tensions: Too Much vs. Too Little

Both cohesion and coupling improvements can be taken too far. Excessively fine-grained modules can be as problematic as overly coarse ones. There's a 'Goldilocks zone' for granularity.

The tension:

Too Coarse (Under-modularized)

•God classes doing everything
•Hard to test individual behaviors
•Changes affect unrelated features
•Hard to find specific functionality
•Teams step on each other
•All-or-nothing deployment

Too Fine (Over-modularized)

•Ravioli code: tiny, scattered pieces
•Hard to understand overall flow
•High coordination overhead
•Duplicated concepts across modules
•Death by abstraction layers
•Simple change requires many files

Finding the right granularity:

Team size heuristic. A module should be small enough that one person can understand it, but large enough that it encapsulates a meaningful concept. If you need a team meeting to explain a simple service, it's too fragmented.
Change frequency alignment. Code that changes together should live together. If every feature request touches 15 files, your modules are too fine. If a one-line bug fix requires understanding 2000 lines of context, too coarse.
Domain concept alignment. Modules should map to domain concepts. If 'Order' is one concept in business terms, having 50 classes each holding one tiny piece of Order logic may be over-decomposition.
Cognitive chunk size. Research suggests 7±2 items in working memory. A module with 3-10 public methods, a package with 3-10 modules, a service with 3-10 endpoints—these match human cognition.
The 'explain it' test. Can you explain what a module does to a new team member in 2-3 minutes? Too long → too big. Need to explain many modules for basic understanding → too fragmented.

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
// ❌ TOO COARSE: One class does everything
class OrderManager {
    createOrder() { } 
    validateOrder() { }
    calculateTax() { }
    calculateShipping() { }
    processPayment() { }
    sendConfirmation() { }
    generateInvoice() { }
    updateInventory() { }
    notifyWarehouse() { }
    trackShipment() { }
    handleReturns() { }
    // ... 50 more methods
}
 
// ❌ TOO FINE: Class-per-operation explosion
class OrderCreator { }
class OrderValidator { }
class OrderTaxCalculator { }
class OrderShippingCalculator { }
class OrderPaymentProcessor { }
class OrderConfirmationSender { }
class OrderInvoiceGenerator { }
class InventoryUpdater { }
class WarehouseNotifier { }
class ShipmentTracker { }
class ReturnHandler { }
// 50+ tiny classes for one bounded context
 
// ✅ BALANCED: Grouped by subdomain/responsibility
class OrderService {
    // Order lifecycle — cohesive concern
    create(items: Item[], customer: Customer): Order { }
    cancel(orderId: string): void { }
    modify(orderId: string, changes: OrderChanges): Order { }
}
 
class OrderPricingService {
    // Pricing calculations — related concern  
    calculateSubtotal(order: Order): Money { }
    calculateTax(order: Order): Money { }
    calculateShipping(order: Order): Money { }
    calculateTotal(order: Order): Money { }
}
 
class OrderFulfillmentService {
    // Fulfillment operations — related concern
    reserve(order: Order): Reservation { }
    ship(order: Order): Shipment { }
    track(orderId: string): TrackingInfo { }
}
 
class OrderNotificationService {
    // Communications — related concern
    sendConfirmation(order: Order): void { }
    sendShippingUpdate(order: Order, status: Status): void { }
    sendDeliveryConfirmation(order: Order): void { }
}

Granularity Evolves

Intentional Coupling: Shared Understanding

Not all coupling is bad. Some coupling reflects genuine coordination requirements. Trying to eliminate it can create worse problems—hidden dependencies, inconsistent behavior, or duplicated logic.

Types of intentional coupling:

Contract coupling: Services share API contracts. This coupling is intentional—it defines the agreement between them. Trying to eliminate it creates ambiguity.
Domain model coupling: Bounded contexts share certain concepts (Customer ID, Product SKU). This coupling reflects business reality—these identifiers must match across systems.
Transactional coupling: Some operations genuinely require consistency across modules. A money transfer between accounts must either complete fully or not at all.
Consistency coupling: Multiple systems display the same data. They're coupled to a consistency requirement—users expect the same information everywhere.

When trying to decouple creates problems:

Consider a system where Order Service and Inventory Service must agree on whether an order can be fulfilled. You could:

Option A: Tight coupling (synchronous call)

Order Service calls Inventory Service before confirming order
Coupled, but always consistent
If Inventory is down, orders fail

Option B: Loose coupling (eventual consistency)

Order Service publishes event
Inventory Service eventually processes it
Decoupled, but may accept unfulfillable orders
Requires compensation logic for conflicts

Option C: Distributed transaction

Two-phase commit across services
Still coupled, plus complex failure modes
Often worst of both worlds

None of these is universally superior. The right choice depends on business requirements—can you tolerate occasional inconsistency? How critical is availability? What's the compensation cost?

Guidelines for Intentional Coupling

•Make it explicit. If coupling is intentional, document it. Don't hide dependencies—surface them in architecture diagrams, API contracts, and ADRs (Architecture Decision Records).
•Couple on stable abstractions. If you must couple, couple to things unlikely to change. IDs, domain events, and core entity names are more stable than implementation details.
•Centralize shared definitions. If multiple services need the same event schema, maintain it in a shared schema registry. Coupling to a single source of truth is better than drifting duplicates.
•Accept coupling within boundaries. Inside a bounded context, coupling is expected. Objects within the same aggregate can be tightly coupled. Reserve decoupling effort for cross-boundary communication.
•Distinguish data coupling from structural coupling. Sharing data formats (data coupling) is often acceptable. Sharing internal structures (structural coupling) is not.

The Tight/Loose Spectrum Within a System

Time, Budget, and Reality

The tension:

Refactoring for cohesion takes time. Introducing abstractions for decoupling takes time. Writing comprehensive tests that enable safe refactoring takes time. And time is finite.

Context Factors Affecting Cohesion/Coupling Investment
Factor	Invest More In Quality	Accept More Shortcuts
Lifespan	Long-lived production system	Short-term PoC or spike
Scale	High-traffic, high-criticality	Internal tool, few users
Team size	Large team, multiple squads	Solo developer, small team
Change rate	Rapidly evolving requirements	Stable, well-understood domain
Hiring	Expect team turnover/growth	Stable, long-tenured team
Risk	Failure has high cost	Failure is recoverable

Strategies for constrained situations:

Strategic debt. Accept debt consciously and track it. Document what compromises you made and why. Create tickets for remediation. This prevents 'forgotten' tech debt that compounds silently.
Incremental improvement. You don't have to fix everything at once. Improve cohesion as you touch files. Reduce coupling one module at a time. The Boy Scout Rule: leave code better than you found it.
Pay down debt with interest. When you do have time for refactoring, prioritize debt that's 'charging interest'—code that's frequently modified, causing bugs, or blocking new features.
Build scaffolding. Even if you can't refactor immediately, you can add tests, add documentation, and add interfaces that enable future refactoring.
Negotiate scope, not quality. When pressed for time, negotiate delivering fewer features to a higher standard rather than many features to a low standard. Technical debt slows future features.

The Trap of 'We'll Fix It Later'

Team and Organization Factors

Conway's Law:

"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

Organizational Factors in Design Decisions

•Team boundaries → Module boundaries. Code owned by different teams should be loosely coupled. Teams can't coordinate on every change, so their code shouldn't require it. Apply the 'inverse Conway maneuver': structure teams to match desired architecture.
•Expertise distribution. If only one person understands a module, high internal cohesion matters less (they hold the context). But what happens when they leave? For knowledge resilience, cohesion aids onboarding.
•Communication costs. Cross-team coupling requires cross-team communication. Every dependency = potential meeting, delay, misunderstanding. Minimize dependencies across team boundaries.
•Deployment independence. Teams want to deploy their changes without coordinating with others. Coupling blocks independent deployment, creating calendar tetris and release bottlenecks.
•Ownership clarity. Who fixes bugs in tightly coupled code? If coupling crosses teams, ownership disputes arise. Clear boundaries enable clear ownership.

Example: Microservices and teams

Microservices architecture isn't just a technical pattern—it's an organizational pattern. Each service is (ideally) owned by one team that can develop, deploy, and operate it independently.

Conversely, if you have 300 developers sharing one monolith, even high internal cohesion doesn't prevent bottlenecks—everyone's working in the same repo, same deploy pipeline, same codebase.

The Inverse Conway Maneuver

Evolution Over Perfection

The tension:

Principles for evolutionary architecture:

Defer decisions. Don't lock in choices that can be deferred. Use interfaces to defer implementation choice. Use feature flags to defer feature decisions. Use A/B tests to defer UX decisions. Late binding preserves options.
Make decisions reversible. When you must decide, choose options that are easy to reverse. A database migration is hard to reverse; an abstraction layer in front of it can be swapped. Prefer reversible over 'optimal but irreversible.'
Run experiments. Unsure about an architectural choice? Prototype alternatives. Build a thin slice with Option A and Option B. See which works better in practice before committing.
Build seams. Even if you don't currently need to replace a component, design the seam where replacement would happen. The interface might never be re-implemented, but its existence clarifies boundaries.
Accept impermanence. Today's brilliant design will be tomorrow's legacy code. Don't optimize for a future that may never arrive. Build for now, enable change later.

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
// Today: Simple in-memory implementation
// Tomorrow: Could be Redis, could be database, could be external service
// The seam enables change without rewriting consumers
 
interface FeatureFlags {
    isEnabled(flag: string): boolean;
    getVariant(flag: string): string | null;
}
 
// Current implementation: simple config file
class ConfigFileFeatureFlags implements FeatureFlags {
    private config: Record<string, boolean | string>;
    
    constructor(configPath: string) {
        this.config = JSON.parse(fs.readFileSync(configPath, 'utf-8'));
    }
    
    isEnabled(flag: string): boolean {
        return this.config[flag] === true;
    }
    
    getVariant(flag: string): string | null {
        const value = this.config[flag];
        return typeof value === 'string' ? value : null;
    }
}
 
// Future: When we need dynamic flags, experimentation, A/B testing
class LaunchDarklyFeatureFlags implements FeatureFlags {
    constructor(private client: LaunchDarklyClient, private user: User) {}
    
    isEnabled(flag: string): boolean {
        return this.client.variation(flag, this.user, false);
    }
    
    getVariant(flag: string): string | null {
        return this.client.variation(flag, this.user, null);
    }
}
 
// Application code doesn't know or care which implementation
// Switching is a configuration change, not a code change
class CheckoutFlow {
    constructor(private flags: FeatureFlags) {}
    
    checkout(cart: Cart): void {
        if (this.flags.isEnabled('new-checkout-ui')) {
            this.renderNewCheckout(cart);
        } else {
            this.renderLegacyCheckout(cart);
        }
    }
}

The 'Last Responsible Moment'

Summary: Living with Trade-offs

We've explored the tensions and trade-offs inherent in cohesion and coupling decisions. Let's consolidate the key insights as guiding principles:

Key Trade-off Principles

•Cohesion and reusability conflict — Highly focused modules are less generic; layer specific wrappers over reusable cores.
•Decoupling has performance costs — Profile before assuming overhead matters; accept coupling in hot paths when truly necessary.
•Both over- and under-modularization hurt — Find the Goldilocks zone where modules are comprehensible units, not too large, not too fragmented.
•Some coupling is intentional — Shared contracts, domain identifiers, and consistency requirements are valid coupling; make them explicit.
•Constraints are real — Time, budget, skills, and team structure affect viable options; accept strategic debt when necessary.
•Architecture mirrors organization — Align module boundaries with team boundaries; use Conway's Law intentionally.
•Evolution trumps perfection — Design for change, defer decisions, build seams, accept impermanence.

Closing reflection:

Module Complete