Architecture Partitioning Strategies

Key Insight

Partitioning an architecture is a pivotal decision, inherently involving trade-offs, aligning with the 'First Law of Software Architecture' that states 'everything in software is a trade-off.' Architects can choose from several methods for top-level partitioning, with the two most prevalent styles being technical partitioning and domain partitioning. Each approach fundamentally influences the architecture's overarching structure and the organization of its code, often involving nested components within these primary divisions.

Technical partitioning organizes components based on their technical capabilities, such such as 'presentation', 'business rules', 'services', or 'persistence'. This method simplifies locating code related to specific technical concerns, as, for example, all persistence code resides within a single layer. While this approach offers beneficial levels of decoupling, where changes in one layer might only affect adjacent ones, a significant drawback is that business workflows, such as 'CatalogCheckout', often span across these technical layers, effectively 'smearing' the domain functionality throughout multiple components. This style often aligns with patterns like the layered monolith and is influenced by 'Conway’s Law', which suggests that system designs mirror an organization's communication structures, frequently leading to teams being segregated by technical roles.

In contrast, domain partitioning organizes top-level components around specific business domains or workflows, drawing inspiration from Domain-Driven Design. This method provides a more accurate reflection of how businesses operate and aligns well with modern architectural styles such as modular monoliths and microservices. Its advantages include facilitating the 'Inverse Conway Maneuver' to establish cross-functional teams and ensuring that message flow more closely matches the problem domain, thereby simplifying migration to distributed architectures. Although customization code might appear in multiple locations, this approach enhances modularity and decoupling by consolidating workflow-related logic, signifying a notable industry shift towards domain-centric architectural organization.