Core Idea
Architecture partitioning determines how a system is divided into components. The two fundamental approaches—technical partitioning (organizing by technical layers) and domain partitioning (organizing by business capabilities)—represent fundamentally different ways of thinking about system structure, each with distinct trade-offs for maintainability, scalability, and team organization.
The Two Fundamental Approaches
Technical Partitioning (Layered Architecture):
- Organizes components by technical capabilities and concerns
- Separates presentation logic, business logic, and data access into distinct layers
- Mirrors traditional team structures (frontend team, backend team, database team)
- Creates horizontal slicing: broad, shallow components that share data structures; any feature change requires coordination across layers
Domain Partitioning (Modular Architecture):
- Organizes components by business capabilities or domains
- Each component encapsulates all technical layers needed for a specific business function (e.g., Order Management, Payment Processing, Inventory—each with its own presentation, logic, and data access)
- Aligns with domain-driven design; enables teams to own complete business capabilities
- Creates vertical slicing: narrow, deep components that are more independent; enables parallel development but may duplicate technical infrastructure
Conway’s Law Reinforcement: Organizations naturally produce architectures that mirror their communication structures—technical teams trend toward technical partitioning; domain-aligned teams trend toward domain partitioning.
Context-Dependent Choice:
- Domain partitioning favored when prioritizing: independent deployability, scalability, fault isolation
- Technical partitioning favored when prioritizing: code reuse, technical consistency, simplicity
Why This Matters
The partitioning approach shapes everything downstream: component boundaries, team structure, deployment strategies, and the system’s ability to evolve. Choosing the wrong approach creates persistent friction—domain partitioning in a system needing maximum code reuse leads to duplication; technical partitioning in a system needing independent scaling creates deployment bottlenecks. Making this decision explicit and intentional, rather than accepting it by default, is a fundamental architectural responsibility.
Related Concepts
- Component-Definition — What components are and how they manifest partitioning decisions
- Component-Identification-Process — How to systematically identify components
- Component-Granularity — Determining the appropriate size and scope of components
- Conway’s-Law — How organizational structure influences architecture partitioning
- Modularity — The logical foundation underlying physical partitioning
- Cohesion — Measuring how well elements within a partition belong together
- Architecture-Quantum — Understanding deployable units that emerge from partitioning
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
- Discusses technical vs. domain partitioning in component identification
- 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.