domains / software-engineering / design-pattern-selection / patterns

patterns

Skill card

combined

The two skills share the name 'patterns' but address completely different domains. The first is a Unity-specific guide for choosing game development patterns (ScriptableObjects, state machines, object pools) and includes a 'Decision Lab' methodology for comparing implementation trade-offs. The second is a general software architecture reference for distributed systems patterns (CQRS, Event Sourcing, Saga, Circuit Breaker). Neither is a reproduction of the other; they are distinct reference documents for different engineering contexts.

Repositories

Other copies

Combined skill

# Design Pattern Selection

This skill covers two distinct domains of design patterns. Select the relevant section based on the project context.

## 1. Unity / Game Development Patterns

Use this section for Unity C# development.

**Guardrails:**
- Recommend at most 1-3 patterns.
- Explain why simpler options are not enough.

**Pattern Guide:**
- **ScriptableObject**: Use for authored config, shared static data, event channels. Avoid for per-run mutable gameplay state.
- **C# events / delegates**: Use for one-to-many notifications with clear ownership. Avoid for imperative flows needing ordering or return values.
- **Global event bus**: Use sparingly for broad decoupled notifications. Avoid as default for coupling.
- **Interfaces**: Use for multiple implementations or clear dependency boundaries. Avoid adding without a real seam.
- **State machine**: Use for actors with mutually exclusive states. Avoid when booleans suffice.
- **Object pool**: Use for frequent spawn/despawn (bullets, VFX). Avoid for rare objects.
- **Service layer**: Use for cross-scene systems with explicit bootstrap. Avoid hidden singletons.
- **Generics / attributes**: Use to remove boilerplate with type safety. Avoid if they reduce readability.

**Decision Lab Methodology:**
For non-trivial decisions, compare 2-3 plausible implementations side-by-side on:
1. Switch cost (enter/exit state)
2. Per-frame/query cost
3. Code complexity
4. Failure modes

*Example: Pausing AI on 100 enemies*
- **Field flag**: O(N) writes, N branch tests/frame, lowest complexity, risk of forgotten guards.
- **enabled = false**: O(N) writes, zero per-frame cost, low complexity, risk of OnEnable/Disable side effects.
- **Subset list**: O(N) list move, proportional cost to active count, highest complexity, risk of list desync.

*Skip this exercise if N ≤ 10 or state changes once per session.*

**Output Format:**
- Recommended pattern(s)
- Why they fit
- Why not the simpler alternative
- Minimal implementation boundary
- Known tradeoffs

## 2. Distributed Systems / Architecture Patterns

Use this section for microservices and distributed system design.

**Key Patterns:**
- **CQRS**: Separate read/write models. Use when read load >> write load. Trade-off: eventual consistency.
- **Event Sourcing**: Store state as immutable events. Use for audit trails/compliance. Trade-off: query complexity.
- **Saga**: Manage distributed transactions via local transactions + compensations. Use for multi-service workflows. Trade-off: debugging complexity.
- **Circuit Breaker**: Fail fast on downstream errors. Use for external service calls. Trade-off: fallback logic required.
- **Bulkhead**: Isolate resources (threads/processes) per service. Use to prevent resource starvation. Trade-off: resource overhead.
- **Strangler Fig**: Incrementally replace monoliths. Use for legacy migration. Trade-off: long-term maintenance of two systems.
- **Outbox Pattern**: Ensure reliable event publishing. Use for transactional consistency.
- **Consistent Hashing**: Distribute data across nodes. Use for scalable caching/storage.
- **Backpressure**: Control data flow to prevent overload. Use for streaming systems.
- **Leader Election**: Select a single coordinator. Use for stateful services.
- **Two-Phase Commit**: Atomic commit across resources. Use sparingly due to availability impact.

**Implementation Notes:**
- For Circuit Breakers: Start with 50% failure rate over 10 requests, 30s open time.
- For Sagas: Choose Choreography (decentralized) or Orchestration (centralized) based on workflow complexity.
- For CQRS: Use CDC (e.g., Debezium) to sync write to read models.