/architecture-paradigms

name: architecture-paradigms
description: Selects and routes to the right architecture paradigm. Use when choosing patterns for a new system or comparing trade-offs before making architecture decisions.
alwaysApply: false
category: architecture-decision
tags:
- architecture
- patterns
- selection
- implementation
- adr
dependencies:
- architecture-paradigm-functional-core
- architecture-paradigm-hexagonal
- architecture-paradigm-domain-driven
- architecture-paradigm-cqrs-es
- architecture-paradigm-event-driven
- architecture-paradigm-layered
- architecture-paradigm-modular-monolith
- architecture-paradigm-microkernel
- architecture-paradigm-microservices
- architecture-paradigm-service-based
- architecture-paradigm-space-based
- architecture-paradigm-pipeline
- architecture-paradigm-serverless
- architecture-paradigm-client-server
tools: []
usage_patterns:
- paradigm-selection
- architecture-review
- implementation-planning
- adr-creation
complexity: intermediate
model_hint: standard
estimated_tokens: 280

When NOT To Use

• The paradigm is already chosen, so go straight to that paradigm's skill
• Reviewing an existing design against its ADRs (use

`pensive:architecture-review`)

Table of Contents

• [Quick Scenario Router](#quick-scenario-router)
• [3-Step Selection Workflow](#3-step-selection-workflow)
• [Available Paradigm Skills](#available-paradigm-skills)
• [Integration with Other Skills](#integration-with-other-skills)
• [Exit Criteria](#exit-criteria)

Architecture Paradigm Router

This skill helps you **select** the right architecture paradigm(s) for your system, then **routes** you to the specific paradigm skill for implementation details.

Quick Scenario Router

Match your needs to the recommended paradigm:

| Your Scenario | Primary Paradigm | Load Skill | |---------------|------------------|------------| | **Enterprise app with multiple teams** | Microservices or Modular Monolith | `architecture-paradigm-microservices` or `architecture-paradigm-modular-monolith` | | **Complex business rules & testing** | Functional Core, Imperative Shell | `architecture-paradigm-functional-core` | | **Real-time/event processing** | Event-Driven Architecture | `architecture-paradigm-event-driven` | | **Legacy system modernization** | Hexagonal (Ports & Adapters) | `architecture-paradigm-hexagonal` | | **Cloud-native/bursty workloads** | Serverless | `architecture-paradigm-serverless` | | **ETL/data processing pipeline** | Pipeline Architecture | `architecture-paradigm-pipeline` | | **Simple CRUD app** | Layered Architecture | `architecture-paradigm-layered` | | **Command/query separation** | CQRS and Event Sourcing | `architecture-paradigm-cqrs-es` | | **Rich business rules to model** | Domain-Driven Design | `architecture-paradigm-domain-driven` |

**One of these is not like the others.** Domain-Driven Design answers "what are the concepts and what do we call them." The rest answer "where does the code go." DDD composes with a structural paradigm (commonly layered, hexagonal, or modular monolith) rather than competing with it, so selecting it does not mean deselecting one of the others.

3-Step Selection Workflow

Step 1: Define Your Needs

**Primary Concerns** (select all that apply):

• **Testability**: Isolate business logic → `functional-core` or `hexagonal`
• **Team Autonomy**: Independent deployment → `microservices` or `modular-monolith`
• **Infrastructure Flexibility**: Swap databases/frameworks → `hexagonal`
• **Real-time Scaling**: Variable loads with events → `event-driven` or `space-based`
• **Simplicity**: Maintainable without complexity → `layered` or `modular-monolith`
• **Legacy Integration**: Work with existing systems → `hexagonal` or `microkernel`

**System Context**:

• **Team Size**: `< 5` → Layered/Functional Core | `5-15` → Modular Monolith | `15-50` → Microservices | `50+` → Microservices/Space-Based
• **Domain Complexity**: `Simple` → Layered | `Moderate` → Hexagonal/Modular Monolith | `Complex` → Functional Core/CQRS | `Highly Complex` → Microservices/Event-Driven

Step 2: Evaluate Paradigms

Based on your needs from Step 1, review these options:

**For Testability & Business Logic**

• Load `architecture-paradigm-functional-core` - Isolates business logic from infrastructure
• Load `architecture-paradigm-hexagonal` - Clear domain/infrastructure boundaries

**For Team Autonomy**

• Load `architecture-paradigm-microservices` - Independent deployment and scaling
• Load `architecture-paradigm-modular-monolith` - Team autonomy without distributed complexity

**For Infrastructure Flexibility**

• Load `architecture-paradigm-hexagonal` - Swap infrastructure without domain changes

**For Simplicity & Maintainability**

• Load `architecture-paradigm-layered` - Simple, well-understood separation

**For Rich Business Rules**

• Load `architecture-paradigm-domain-driven` - Models the business in its

own language. Pair it with whichever structural paradigm you picked above; it does not replace one. Skip it when the domain is CRUD over a form, where the model would just be the schema under a new name.

**For Real-time Event Processing**

• Load `architecture-paradigm-event-driven` - Scalable, decoupled processing
• Load `architecture-paradigm-space-based` - In-memory data grids for linear scalability

**For Legacy Integration**

• Load `architecture-paradigm-microkernel` - Plugin architecture for extensible platforms
• Load `architecture-paradigm-hexagonal` - Adapters for external systems

Step 3: Load Paradigm Skill for Implementation

Once you've selected your paradigm(s), load the specific skill for detailed guidance:

# Example: You selected Hexagonal Architecture
Skill(archetypes:architecture-paradigm-hexagonal)

The individual paradigm skill provides:

• ✅ Complete implementation guide
• ✅ ADR templates
• ✅ Migration checklist
• ✅ Code examples
• ✅ Testing strategies
• ✅ Risk assessments

Available Paradigm Skills

| Paradigm |