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
Component granularity is one of the most consequential architectural decisions. Traditional guidance—“high cohesion, low coupling”—provides a starting point but doesn’t capture the full decision space. Granularity must be evaluated through three lenses:
Lens 1: Architectural Characteristics Alignment
- Components should align with the characteristics they need to satisfy (scalability, deployability, security)
- Different requirements suggest different component boundaries—e.g., a payment component needs higher security than a product catalog, justifying separation even when functionally related
Lens 2: Domain-Driven Boundaries
- Component boundaries often map to bounded contexts
- A component should encapsulate a cohesive business capability; when functionality crosses domain boundaries, it signals improper granularity or the need for explicit integration patterns
Lens 3: Team Structure and Conway’s Law
- Component boundaries that don’t match team boundaries create coordination overhead and organizational friction
- If teams are organized by domain, components should align with those domains
Why This Matters
Getting granularity wrong has cascading consequences:
- Overly coarse: Deployment bottlenecks (changing one piece requires redeploying everything) and large test blast radius
- Overly fine: Distributed system complexity—more network calls, more failure points, more operational overhead
Granularity decisions are rarely static. A monolithic component suited to a startup may need splitting as scale demands increase. The key is making granularity decisions consciously with clear rationale tied to architectural characteristics—not defaulting to technical convenience or architectural trends.
Related Concepts
- Component-Definition
- Component-Identification-Process
- Architecture-Quantum
- Modularity
- Cohesion
- Coupling
- Conway’s-Law
Sources
- Richards, Mark and Neal Ford (2020). Fundamentals of Software Architecture: An Engineering Approach. O’Reilly Media. ISBN: 978-1-492-04345-4.
- Chapter 8: Component-Based Thinking
- Available: https://www.oreilly.com/library/view/fundamentals-of-software/9781492043447/
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.