Complete guide for enterprise architecture patterns including domain-driven design, event sourcing, CQRS, saga patterns, API gateway, service mesh, and scalability

Enterprise Architecture Patterns A comprehensive skill for mastering enterprise architecture patterns, distributed systems design, and scalable application development. This skill covers strategic and tactical patterns for building robust, maintainable, and scalable enterprise systems. When to Use This Skill Use this skill when: Designing microservices architectures for distributed systems Implementing domain driven design (DDD) in complex business domains Building event driven architectures with event sourcing and CQRS Designing saga patterns for distributed transactions Implementing API gateways and service mesh architectures Scaling applications horizontally and vertically Building resilient systems with fault tolerance Migrating monoliths to microservices Designing multi tenant SaaS architectures Implementing backend for frontend (BFF) patterns Building real time systems with event streaming Architecting cloud native applications Core Architectural Concepts System Design Fundamentals Separation of Concerns Divide systems into distinct sections where each section addresses a separate concern, reducing coupling and increasing cohesion. Modularity Design systems as collections of independent modules that can be developed, tested, and deployed separately. Abstraction Hide complex implementation details behind simple interfaces, making systems easier to understand and modify. Scalability Dimensions Horizontal scaling: Add more machines/instances Vertical scaling: Add more resources to existing machines Data scaling: Partition data across multiple stores Functional scaling: Decompose by business capability Consistency Models Strong consistency: All nodes see the same data at the same time Eventual consistency: All nodes will eventually see the same data Causal consistency: Related operations see consistent state Read your writes consistency: Users see their own updates immediately CAP Theorem In distributed systems, you can only guarantee two of three properties: Consistency: All nodes see the same data Availability: Every request receives a response Partition tolerance: System continues despite network failures Distributed Computing Fallacies 1. The network is reliable 2. Latency is zero 3. Bandwidth is infinite 4. The network is secure 5. Topology doesn't change 6. There is one administrator 7. Transport cost is zero 8. The network is homogeneous Domain Driven Design (DDD) Strategic Design Patterns Bounded Context A bounded context is an explicit boundary within which a domain model is consistent and valid. It defines the scope where particular terms, definitions, and rules apply. Key Principles: Each bounded context has its own ubiquitous language Models within a context are consistent Cross context integration requires translation Contexts align with business capabilities Implementation: Context Mapping Patterns: 1. Shared Kernel : Two contexts share a subset of the domain model Use when: Teams are closely coordinated Risk: Changes affect multiple contexts 2. Customer Supplier : Downstream context depends on upstream Use when: Clear dependency direction exists Pattern: Upstream provides defined API 3. Conformist : Downstream conforms to upstream model Use when: Upstream is external/unchangeable Pattern: Adapt to external API 4. Anti Corruption Layer : Translate between contexts Use when: Protecting from legacy or external systems Pattern: Adapter/facade to translate models 5. Separate Ways : Contexts are completely independent Use when: No integration needed Pattern: Duplicate functionality if necessary 6. Open Host Service : Well defined protocol for integration Use when: Multiple consumers need access Pattern: REST API, GraphQL, gRPC 7. Published Language : Shared, well documented language Use when: Industry standards exist Pattern: XML schemas, JSON schemas, OpenAPI Ubiquitous Language A shared vocabulary between developers and domain experts used consistently in code, documentation, and conversations. Building Ubiquitous Language: Tactical Design Patterns Entities Objects with unique identity that persist over time, tracking continuity and lifecycle. Characteristics: Unique identifier (ID) Mutable state Lifecycle (created, modified, deleted) Equality based on identity, not attributes Implementation: Value Objects Immutable objects defined by their attributes rather than identity, representing descriptive aspects of the domain. Characteristics: No unique identifier Immutable (cannot change state) Equality based on all attributes Often passed by value Can be shared safely Implementation: Aggregates Clusters of entities and value objects with clear consistency boundaries, accessed through a single root entity. Key Principles: One aggregate = one transaction boundary External references only to aggregate root Root enforces all invariants Small aggregates perform better Eventual consistency between aggregates Design Rules: 1. Model true invariants in consistency boundaries 2. Design small aggregates 3. Reference other aggregates by identity only 4. Update other aggregates using eventual consistency 5. Use repositories to retrieve aggregates Implementation: Domain Events Events that represent something significant that happened in the domain, enabling loose coupling and eventual consistency. Characteristics: Past tense naming (OrderPlaced, PaymentProcessed) Immutable Include all necessary information Timestamped Often include aggregate ID Implementation: Repositories Abstraction for accessing aggregates, providing collection like interface while hiding persistence details. Principles: One repository per aggregate root Collection oriented interface Hide database implementation Return fully formed aggregates Support querying by ID and business criteria Implementation: Domain Services Operations that don't naturally belong to any entity or value object, encapsulating domain logic that involves multiple aggregates. When to Use: Logic spans multiple aggregates Operation is a significant domain concept Behavior doesn't fit naturally in entity or value object Implementation: Event Sourcing Event sourcing persists the state of a system as a sequence of events rather than storing current state. The current state is derived by replaying events. Core Concepts Event Store Append only log of all events that have occurred in the system. Event Stream Sequence of events for a specific aggregate, ordered by time. Projection Read model built by processing events, optimized for queries. Snapshot Cached state at a point in time to avoid replaying all events. Implementation Snapshots Optimize performance by periodically saving aggregate state: CQRS (Command Query Responsibility Segregation) Separate read and write operations into different models, optimizing each for its specific use case. Architecture Implementation Saga Pattern Manage distributed transactions across multiple services using a sequence of local transactions coordinated by a saga. Orchestration Based Saga A central orchestrator coordinates all saga participants. Choreography Based Saga Services coordinate through events without central orchestrator. API Gateway Pattern Single entry point for clients, routing requests to appropriate microservices and handling cross cutting concerns. Implementation Backend for Frontend (BFF) Pattern Service Mesh Pattern Infrastructure layer for service to service communication providing observability, traffic management, and security. Key Features Resilience Patterns Circuit Breaker Prevent cascading failures by stopping requests to failing services. Retry Pattern Automatically retry failed operations with exponential backoff. Bulkhead Pattern Isolate resources to prevent failures from affecting entire system. Timeout Pattern Prevent indefinite waits by setting time limits. Fallback Pattern Provide alternative response when operation fails. Combined Resilience Strategy Scalability Patterns Horizontal Scaling (Scale Out) Add more instances to handle increased load. Caching Strategies Database Sharding Best Practices Architecture Design 1. Start with the domain : Understand business requirements before choosing patterns 2. Keep it simple : Don't over engineer; add complexity only when needed 3. Design for failure : Assume services will fail; build resilience 4. Loose coupling : Services should be independent and deployable separately 5. High cohesion : Group related functionality together 6. API first design : Define contracts before implementation 7. Versioning strategy : Plan for API evolution from the start 8. Observability : Build in logging, metrics, and tracing from day one Domain Driven Design 1. Collaborate with domain experts : Build shared understanding 2. Use ubiquitous language : Consistent terminology everywhere 3. Model bounded contexts : Clear boundaries prevent model confusion 4. Small aggregates : Better performance and clearer boundaries 5. Reference by ID : Aggregates reference others by identity 6. Protect invariants : Aggregate roots enforce all business rules 7. Domain events : Capture important business occurrences 8. Repository per aggregate : One repository per aggregate root Event Sourcing & CQRS 1. Event naming : Use past tense, business meaningful names 2. Event immutability : Never modify published events 3. Event versioning : Plan for event schema evolution 4. Snapshots : Use for long event streams 5. Idempotent handlers : Events may be processed multiple times 6. Separate concerns : Different models for read and write 7. Eventual consistency : Accept and communicate delay 8. Monitoring : Track projection lag and event processing Microservices 1. Service size : Small enough to understand, large enough to provide value 2. Data ownership : Each service owns its data 3. Asynchronous communication : Prefer events over synchronous calls 4. Service discovery : Dynamic service location 5. Configuration management : Centralized, environment specific config 6. Deployment independence : Services deploy without coordinating 7. Failure isolation : Circuit breakers and bulkheads 8. Distributed tracing : Correlation IDs across service calls Performance & Scalability 1. Measure first : Profile before optimizing 2. Cache strategically : Right layer, right data, right TTL 3. Async processing : Move slow operations to background 4. Connection pooling : Reuse database/HTTP connections 5. Pagination : Never return unbounded result sets 6. Compression : Reduce network transfer size 7. CDN usage : Serve static assets from edge locations 8. Database indexes : Index query patterns, not all columns Security 1. Defense in depth : Multiple security layers 2. Least privilege : Minimal permissions necessary 3. Encrypt in transit : TLS for all network communication 4. Encrypt at rest : Sensitive data encrypted in storage 5. Input validation : Validate and sanitize all inputs 6. Authentication : Verify identity (JWT, OAuth) 7. Authorization : Verify permissions (RBAC, ABAC) 8. Audit logging : Track security relevant events Testing 1. Test pyramid : Many unit tests, fewer integration, few E2E 2. Test behavior : Focus on business logic, not implementation 3. Contract testing : Verify API contracts between services 4. Chaos engineering : Test failure scenarios 5. Performance testing : Load test before production 6. Security testing : Automated vulnerability scanning 7. Smoke tests : Quick validation after deployment 8. Canary dep

enterprise-architecture-patterns