Manu's Vault

Component Granularity

3 min readStatus:Seedling

Core Idea

Component granularity refers to the size and scope of components in a system—determining how much functionality to encapsulate within a single component versus splitting across multiple components. The right granularity balances the need for cohesion, independence, and alignment with architectural characteristics.

Understanding Component Granularity

Consequential Decision: Component granularity is one of the most consequential architectural decisions:

  • Determines how easily a system can evolve, scale, and be maintained
  • Too coarse-grained: Components bundle unrelated functionality together
    • Reduces cohesion
    • Creates unnecessary coupling
  • Too fine-grained: Create excessive problems
    • Inter-component communication overhead
    • Operational complexity
    • Cognitive burden for developers

Beyond Traditional Guidance: The traditional guidance—“high cohesion, low coupling”—provides a starting point but doesn’t capture the full decision space:

  • Component granularity must be evaluated through multiple lenses

Lens 1: Architectural Characteristics Alignment:

  • Components should align with the architectural characteristics they need to satisfy
  • If different parts of the system have different scalability, deployability, or security requirements, those differences suggest component boundaries
  • Example: A payment processing component may need higher security and audit characteristics than a product catalog component, justifying separate components even if they’re functionally related

Lens 2: Domain-Driven Boundaries:

  • Component boundaries often map to bounded contexts from domain-driven design
  • A component should encapsulate a cohesive business capability with clear responsibilities
  • Signal: When functionality crosses domain boundaries, it signals either:
    • Improper component granularity
    • The need for explicit integration patterns

Lens 3: Team Structure and Conway’s Law:

  • Component granularity interacts with organizational structure
  • Conway’s Law: Systems mirror the communication structures of the organizations that build them
  • Alignment principle:
    • If teams are organized by domain, components should align with those domains
    • If component boundaries don’t match team boundaries, you create:
      • Coordination overhead
      • Organizational friction

Why This Matters

Cascading Consequences: Getting component granularity wrong has cascading consequences:

Overly Coarse Components:

  • Create deployment bottlenecks—changing one piece of functionality requires redeploying everything
  • Create testing challenges because the blast radius of any change is large

Overly Fine Components:

  • Create distributed system complexity:
    • More network calls
    • More potential failure points
    • More operational overhead

Evolving Granularity: The choice of component granularity is rarely static:

  • As systems evolve, characteristics change
  • Example: A monolithic component that works well for a startup may need to be split as scale demands increase
  • The key: Make granularity decisions consciously, with clear rationale tied to architectural characteristics
  • Avoid: Defaulting to technical convenience or following architectural trends

Sources

Note

This content was drafted with assistance from AI tools for research, organization, and initial content generation. All final content has been reviewed, fact-checked, and edited by the author to ensure accuracy and alignment with the author’s intentions and perspective.

Graph View

Backlinks