api: "YAML JSON TOON Database" version: "1.0.0" format: "json" dataset: id: 39 slug: "architectural-design-patterns" title: "Architectural Design Patterns" description: "High-level structural patterns: MVC, MVVM, Microservices, Event-Driven, Layered, Hexagonal (Ports & Adapters), CQRS, Serverless, Service Mesh." category: "Design Patterns" category_slug: "design-patterns" tags: "design-patterns,architectural,mvc,microservices,event-driven,serverless" view_count: 0 created_at: 1777673262 updated_at: 1777673262 data: patterns: - name: "MVC (Model-View-Controller)" category: "Component-Based" description: "Separates application into three components: Model (data/business logic), View (UI presentation), Controller (input handling/orchestration). Promotes separation of concerns." key_principles: - "Separation of concerns: data, UI, control logic isolated" - "Model notifies View of changes (Observer pattern)" - "Controller translates user input into model updates" - "View observes Model (data binding or pull)" - "Multiple Views can observe same Model" benefits: "Modular code structure, testability (test model/controller without UI), parallel development (frontend/backend), reusable models and views." tradeoffs: "Controller can become God object (too much logic), tight coupling between Controller and View in some implementations, complexity for simple UIs, many files for small features." typical_components: - "Model classes (data, validation, business rules)" - "View templates/UI components" - "Controller/Router (handles requests, updates model)" when_to_use: "Applications with rich UI requiring separation, web frameworks (Rails, Django, Spring MVC), desktop apps, team-based development where roles are split." tech_examples: - "Ruby on Rails (MVC)" - "Django (MVC-like, MVT)" - "Spring MVC (Java)" - "ASP.NET MVC" - "Backbone.js (JS MVC)" - "Angular (MVVM variant)" - name: "MVVM (Model-View-ViewModel)" category: "Component-Based" description: "Evolution of MVC for data-binding UIs. View observes ViewModel via data binding; ViewModel exposes data/commands for View, no direct View reference. Model unchanged." key_principles: - "Data binding between View and ViewModel (two-way)" - "ViewModel exposes observable properties (ObservableObject)" - "View handles only presentation (no logic)" - "Commands encapsulate actions (ICommand)" - "ViewModel is UI-agnostic (testable without UI)" benefits: "Excellent testability (ViewModel unit tests), designer-developer collaboration (designers work on XAML, devs on ViewModel), clean separation, reactive programming friendly." tradeoffs: "Data binding can be opaque (hard to debug), memory leaks from event handlers, overkill for simple UIs, learning curve for binding syntax." typical_components: - "Model (data layer)" - "View (XAML/HTML template)" - "ViewModel (bindable properties, commands)" - "Data binding engine (framework-provided)" when_to_use: "Applications with rich data binding (WPF, UWP, Xamarin, SwiftUI, Jetpack Compose), reactive UIs, teams with designer/developer split." tech_examples: - "WPF (Windows Presentation Foundation)" - "Xamarin / .NET MAUI" - "SwiftUI (Apple)" - "Jetpack Compose (Android)" - "Vue.js (Vuex/Pinia inspired by MVVM)" - "Knockout.js" - name: "Microservices Architecture" category: "Distributed Systems" description: "Application as collection of small, independent services. Each service owns its data, runs in its own process, communicates via HTTP/gRPC/messaging. Independently deployable." key_principles: - "Single responsibility per service (bounded context)" - "Decentralized data management (database per service)" - "Independent deployment and scaling" - "Technology diversity (polyglot)" - "Resilience (fault isolation)" - "Automated deployment (CI/CD)" benefits: "Independent scaling per service, team autonomy, tech stack flexibility, fault isolation (one service failure doesn't crash all), easier to understand codebase per service." tradeoffs: "Complex distributed system (network latency, partial failures), debugging/tracing harder, data consistency challenges (eventual consistency), operational overhead (monitoring, logging, deployment), testing integration complex." typical_components: - "API Gateway (routing, auth, rate limiting)" - "Service mesh (Istio, Linkerd)" - "Message broker (Kafka, RabbitMQ)" - "Service registry (Consul, Eureka)" - "Centralized logging (ELK)" - "Distributed tracing (Jaeger, Zipkin)" when_to_use: "Large applications with multiple teams, need independent scaling, varied domains, long-lived complex systems, high availability requirements." tech_examples: - "Netflix OSS (Eureka, Hystrix, Zuul)" - "Amazon AWS (Lambda + API Gateway + SQS)" - "Uber (microservices on Go/Node)" - "Spotify (microservices with Python/Java)" - "Docker + Kubernetes" - "gRPC/protobuf for service comms" - name: "Event-Driven Architecture" category: "Distributed Systems" description: "Components communicate via events (state changes). Producers publish events; Consumers subscribe and react. Loose coupling, asynchronous, highly scalable." key_principles: - "Events represent facts (what happened, not what to do)" - "Publish-subscribe or event streaming" - "Event sourcing (store events as source of truth)" - "Loose coupling (producers don't know consumers)" - "Asynchronous communication" - "Eventually consistent" benefits: "Loose coupling, scalability (can add consumers), resilience (message queues buffer failures), extensibility (new consumers without changing producers), real-time reaction." tradeoffs: "Complexity of messaging infrastructure, debugging/observability harder (distributed traces), eventual consistency, event ordering challenges, message duplication." typical_components: - "Event producers (publish events)" - "Event broker/message broker (Kafka, RabbitMQ)" - "Event consumers/processors" - "Event store (optional, for event sourcing)" - "Event schema registry (Avro, Protobuf)" when_to_use: "Real-time systems, data pipelines, IoT, distributed systems with loose coupling needed, systems needing audit trail (event sourcing), decoupling services." tech_examples: - "Kafka (event streaming)" - "RabbitMQ (AMQP)" - "AWS EventBridge / SNS/SQS" - "Azure Event Hubs" - "Google Cloud Pub/Sub" - "Redis Streams" - name: "Layered Architecture (N-Tier)" category: "Structural" description: "Organizes system into horizontal layers (presentation, business logic, data access). Each layer depends only on layer directly below it. Classic enterprise architecture." key_principles: - "Separation by technical concern (not business domain)" - "Layer dependencies only downward (presentation → business → data)" - "Each layer exposes interfaces to layer above" - "Reusable layers across applications" - "Can be deployed monolithically or distributed tiers" benefits: "Simple to understand, separation of concerns clear, testable layers, technology swapping per layer possible, widely understood." tradeoffs: "Can become monolithic blob (all code in one deployable), single layer failure affects all, network overhead if tiers distributed, layer boundaries may blur over time." typical_components: - "Presentation layer (UI, API endpoints)" - "Business Logic layer (services, domain models)" - "Data Access layer (repositories, DAOs)" - "Database layer (SQL/NoSQL)" when_to_use: "Traditional enterprise applications, CRUD-heavy apps, simple monoliths that may later split, teams familiar with layered approach." tech_examples: - "3-tier architecture (web server, app server, DB)" - "Java EE/Jakarta EE (Servlet → EJB → JDBC)" - "Spring (Controller → Service → Repository)" - ".NET (UI → BLL → DAL)" - name: "Hexagonal Architecture (Ports & Adapters)" category: "Structural" description: "Application core (business logic) is isolated from external concerns (UI, DB, external APIs) via ports (interfaces) and adapters (implementations). Also called Clean Architecture or Onion Architecture." key_principles: - "Core domain at center (independent of frameworks)" - "Ports (interfaces) define required operations" - "Adapters implement ports for specific technologies" - "Dependency rule: outer layers depend on inner layers" - "Framework-agnostic core (testable in isolation)" benefits: "Testable core without infrastructure, technology-agnostic business logic, easy to swap adapters (e.g., MySQL → PostgreSQL), framework independence, clear boundaries." tradeoffs: "More boilerplate/interfaces, may feel over-engineered for simple CRUD apps, learning curve, many small files." typical_components: - "Core domain (entities, use cases, interfaces)" - "Primary adapters (driving: UI, API, CLI)" - "Secondary adapters (driven: DB, external APIs, messaging)" - "Ports (interfaces defining collaborations)" when_to_use: "Long-lived business applications, complex domain logic, need test isolation from infrastructure, framework-agnostic core desired." tech_examples: - "Alistair Cockburn's Hexagonal Architecture" - "Robert C. Martin's Clean Architecture" - "Jeffrey Palermo's Onion Architecture" - "Spring Boot with repository interfaces" - "NestJS (dependency injection, modules)" - name: "CQRS (Command Query Responsibility Segregation)" category: "Structural" description: "Separate read (query) and write (command) operations. Commands modify state (write model); Queries read state (read model). May use separate databases/schemas." key_principles: - "Commands: mutate state, return result/void" - "Queries: read state, return DTO, no side effects" - "Separate models (write model vs read model)" - "Read model optimized for queries (denormalized)" - "Write model enforces invariants and business rules" - "Eventual consistency between models" benefits: "Optimized models for each purpose (writes enforce rules, reads optimized for queries), scalability (read replicas), audit trail from commands, clear separation of concerns." tradeoffs: "Complexity (two models to maintain), eventual consistency (not immediately consistent), increased infrastructure, may not be necessary for simple CRUD." typical_components: - "Command side: Command Handlers, Aggregate Roots, Domain Events" - "Query side: Query Handlers, Read Models/DTOs, Materialized Views" - "Event Bus (sync/async)" - "Separate databases or schemas" when_to_use: "High-read vs write asymmetry, complex domain with business rules, need audit log of all changes, scalability demands separate read/write scaling." tech_examples: - "EventStoreDB (event sourcing + CQRS)" - "Axon Framework (Java)" - "MediatR (C#)" - "NestJS CQRS module" - "Kafka + separate read DB (PostgreSQL read replica)" - name: "Serverless Architecture" category: "Cloud-Native" description: "Applications built using managed services and Functions-as-a-Service (FaaS). No server management; cloud provider handles scaling, availability, infrastructure." key_principles: - "Functions are stateless and ephemeral (short-lived)" - "Event-driven execution (HTTP, queue, timer, stream)" - "Pay-per-use pricing model" - "Auto-scaling from zero to massive scale" - "Infrastructure managed by cloud provider" - "Composition of managed services (DB, storage, queues)" benefits: "No server management, automatic scaling, cost-effective for spiky workloads, faster time-to-market, built-in high availability." tradeoffs: "Vendor lock-in (proprietary services), cold start latency, debugging/monitoring harder, execution time limits (max duration), local testing difficult, distributed transactions complex." typical_components: - "FaaS functions (AWS Lambda, Azure Functions, Google Cloud Functions)" - "Managed services (DynamoDB, S3, API Gateway)" - "Event sources (HTTP, queues, streams, timers)" - "Infrastructure-as-Code (CDK, Terraform)" when_to_use: "Spiky/irregular workloads, APIs and webhooks, event processing (file upload, DB changes), IoT backends, rapid prototypes, microservices on FaaS." tech_examples: - "AWS Lambda + API Gateway + DynamoDB" - "Azure Functions + Cosmos DB" - "Google Cloud Functions + Firestore" - "Netlify/Vercel Functions" - "Serverless Framework" - "AWS Step Functions (orchestration)" - name: "Service Mesh" category: "Infrastructure" description: "Dedicated infrastructure layer for service-to-service communication. Handles load balancing, retries, circuit breaking, observability, security (mTLS) transparently via sidecar proxies." key_principles: - "Sidecar proxy per service (Envoy, Linkerd-proxy)" - "Control plane manages proxies (policy, configuration)" - "Data plane handles traffic (L7 routing)" - "Zero-trust security (mTLS between services)" - "Observability (metrics, logs, traces)" - "Traffic shifting (canary, blue-green)" benefits: "Consistent cross-cutting concerns (no code per service), security (mTLS auto), observability (unified telemetry), traffic management (A/B testing, canary), resilience (retries, circuit breakers)." tradeoffs: "Added complexity (deployment, ops), resource overhead (sidecars), learning curve, may be overkill for small deployments, latency added by proxy." typical_components: - "Sidecar proxy (Envoy) per service instance" - "Control plane (Istio Pilot, Linkerd Controller)" - "Service registry (Kubernetes, Consul)" - "Ingress/Egress gateways" when_to_use: "Large microservices deployments (50+ services), need uniform security/observability, complex traffic routing, service-level policies enforced consistently." tech_examples: - "Istio (most feature-rich)" - "Linkerd (lightweight, easy)" - "Consul Connect" - "AWS App Mesh" - "Kuma" - "NGINX Service Mesh"