nw-architectural-styles-tradeoffslisted

# Architectural Styles: Selection and Trade-offs ## Style Selection Decision Tree Start here. Answer the dominant driver, follow to recommended style. ``` Is the domain complex with rich business rules? YES -> Do you need infrastructure independence and high testability? YES -> Hexagonal / Clean / Onion (functionally equivalent, different terminology) NO -> Is the domain well-understood with clear module boundaries? YES -> Modular Monolith (single deployment, structured boundaries) NO -> Layered Architecture (simple, well-known, fast to start) NO -> Is this a feature-heavy application with independent feature teams? YES -> Vertical Slice (per-feature organization, CQRS-friendly) NO -> Do you need independent deployment and scaling per capability? YES -> Can the team handle distributed system operational complexity? YES -> Microservices NO -> Modular Monolith (extract to services later) NO -> Is the primary concern async workflows or event-driven processing? YES -> Event-Driven Architecture NO -> Is this a data processing pipeline? YES -> Pipe and Filter NO -> Layered Architecture (sensible default) ``` ## Cross-Cutting Comparison Matrix | Style | Dep. Direction | Organization | Deployment | Best For | Team Size | |-------|---------------|-------------|------------|----------|-----------| | Hexagonal/Clean/Onion | Inward (DIP) | Ports + adapters | Single process | Infras