enterprise-architecture-patterns

What this skill does

# 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:**
```typescript
// Example: E-commerce system with multiple bounded contexts

// Sales Context
namespace Sales {
  class Customer {
    customerId: string;
    email: string;
    orderHistory: Order[];

    placeOrder(order: Order): void {
      // Sales-specific logic
    }
  }
}

// Billing Context
namespace Billing {
  class Customer {
    customerId: string;
    paymentMethods: PaymentMethod[];
    invoices: Invoice[];

    processPayment(invoice: Invoice): void {
      // Billing-specific logic
    }
  }
}

// Different models for Customer in different contexts
```

**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:**
```typescript
// Bad: Generic technical terms
class DataProcessor {
  processData(data: any): void {
    // Unclear what this does in business terms
  }
}

// Good: Business domain terms
class OrderFulfillment {
  fulfillOrder(order: Order): void {
    this.pickItems(order.items);
    this.packForShipment(order);
    this.scheduleDelivery(order);
  }

  private pickItems(items: OrderItem[]): void {
    // Business logic using domain 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:**
```typescript
class Order {
  private readonly orderId: string;
  private orderItems: OrderItem[];
  private status: OrderStatus;
  private orderDate: Date;
  private customerId: string;

  constructor(orderId: string, customerId: string) {
    this.orderId = orderId;
    this.customerId = customerId;
    this.orderItems = [];
    this.status = OrderStatus.Draft;
    this.orderDate = new Date();
  }

  // Business behavior
  addItem(product: Product, quantity: number): void {
    if (this.status !== OrderStatus.Draft) {
      throw new Error("Cannot modify confirmed order");
    }
    this.orderItems.push(new OrderItem(product, quantity));
  }

  confirm(): void {
    if (this.orderItems.length === 0) {
      throw new Error("Cannot confirm empty order");
    }
    this.status = OrderStatus.Confirmed;
  }

  // Identity-based equality
  equals(other: Order): boolean {
    return this.orderId === other.orderId;
  }
}
```

#### 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:**
```typescript
class Money {
  readonly amount: number;
  readonly currency: string;

  constructor(amount: number, currency: string) {
    if (amount < 0) {
      throw new Error("Amount cannot be negative");
    }
    this.amount = amount;
    this.currency = currency;
  }

  // Operations return new instances
  add(other: Money): Money {
    if (this.currency !== other.currency) {
      throw new Error("Cannot add different currencies");
    }
    return new Money(this.amount + other.amount, this.currency);
  }

  multiply(factor: number): Money {
    return new Money(this.amount * factor, this.currency);
  }

  // Value-based equality
  equals(other: Money): boolean {
    return this.amount === other.amount &&
           this.currency === other.currency;
  }
}

class Address {
  readonly street: string;
  readonly city: string;
  readonly state: string;
  readonly zipCode: string;
  readonly country: string;

  constructor(
    street: string,
    city: string,
    state: string,
    zipCode: string,
    country: string
  ) {
    this.street = street;
    this.city = city;
    this.state = state;
    this.zipCode = zipCode;
    thi