🎯

designing-architecture

🎯Skill

from cloudai-x/claude-workflow

VibeIndex|
What it does

Designs software architecture by systematically selecting optimal patterns, structuring projects, and making technical decisions based on project requirements and team capabilities.

πŸ“¦

Part of

cloudai-x/claude-workflow(8 items)

designing-architecture

Installation

git cloneClone repository
git clone https://github.com/CloudAI-X/claude-workflow.git
πŸ“– Extracted from docs: cloudai-x/claude-workflow
10Installs
-
AddedFeb 4, 2026

Skill Details

SKILL.md

Designs software architecture and selects appropriate patterns for projects. Use when designing systems, choosing architecture patterns, structuring projects, making technical decisions, or when asked about microservices, monoliths, or architectural approaches.

Overview

# Designing Architecture

Architecture Decision Workflow

Copy this checklist and track progress:

```

Architecture Design Progress:

  • [ ] Step 1: Understand requirements and constraints
  • [ ] Step 2: Assess project size and team capabilities
  • [ ] Step 3: Select architecture pattern
  • [ ] Step 4: Define directory structure
  • [ ] Step 5: Document trade-offs and decision
  • [ ] Step 6: Validate against decision framework

```

Pattern Selection Guide

By Project Size

| Size | Recommended Pattern |

|------|---------------------|

| Small (<10K LOC) | Simple MVC/Layered |

| Medium (10K-100K) | Clean Architecture |

| Large (>100K) | Modular Monolith or Microservices |

By Team Size

| Team | Recommended |

|------|-------------|

| 1-3 devs | Monolith with clear modules |

| 4-10 devs | Modular Monolith |

| 10+ devs | Microservices (if justified) |

Common Patterns

1. Layered Architecture

```

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”

β”‚ Presentation β”‚ ← UI, API Controllers

β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€

β”‚ Application β”‚ ← Use Cases, Services

β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€

β”‚ Domain β”‚ ← Business Logic, Entities

β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€

β”‚ Infrastructure β”‚ ← Database, External APIs

β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

```

Use when: Simple CRUD apps, small teams, quick prototypes

2. Clean Architecture

```

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”

β”‚ Frameworks & Drivers β”‚

β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚

β”‚ β”‚ Interface Adapters β”‚ β”‚

β”‚ β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ β”‚

β”‚ β”‚ β”‚ Application β”‚ β”‚ β”‚

β”‚ β”‚ β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ β”‚ β”‚

β”‚ β”‚ β”‚ β”‚ Domain β”‚ β”‚ β”‚ β”‚

β”‚ β”‚ β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β”‚ β”‚

β”‚ β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ β”‚

β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚

β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

```

Use when: Complex business logic, long-lived projects, testability is key

3. Hexagonal (Ports & Adapters)

```

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”

β”‚ HTTP API β”‚

β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”˜

β”‚ Port

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”€β”€β”€β”

β”‚ β”‚

β”‚ Application β”‚

β”‚ Core β”‚

β”‚ β”‚

β””β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”˜

β”‚ Port

β”Œβ”€β”€β”€β”€β–Όβ”€β”€β”€β”€β”€β”

β”‚ Database β”‚

β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

```

Use when: Need to swap external dependencies, multiple entry points

4. Event-Driven Architecture

```

Producer β†’ Event Bus β†’ Consumer

β”‚

β”œβ”€β†’ Consumer

β”‚

└─→ Consumer

```

Use when: Loose coupling needed, async processing, scalability

5. CQRS (Command Query Responsibility Segregation)

```

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”

β”‚ Commands β”‚ β”‚ Queries β”‚

β”‚ (Write) β”‚ β”‚ (Read) β”‚

β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”˜

β”‚ β”‚

β–Ό β–Ό

Write Model Read Model

β”‚ β”‚

β””β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

β–Ό

Event Store

```

Use when: Different read/write scaling, complex domains, event sourcing

Directory Structure Patterns

Feature-Based (Recommended for medium+)

```

src/

β”œβ”€β”€ features/

β”‚ β”œβ”€β”€ users/

β”‚ β”‚ β”œβ”€β”€ api/

β”‚ β”‚ β”œβ”€β”€ components/

β”‚ β”‚ β”œβ”€β”€ hooks/

β”‚ β”‚ β”œβ”€β”€ services/

β”‚ β”‚ └── types/

β”‚ └── orders/

β”‚ β”œβ”€β”€ api/

β”‚ β”œβ”€β”€ components/

β”‚ └── ...

β”œβ”€β”€ shared/

β”‚ β”œβ”€β”€ components/

β”‚ β”œβ”€β”€ hooks/

β”‚ └── utils/

└── app/

└── ...

```

Layer-Based (Simple apps)

```

src/

β”œβ”€β”€ controllers/

β”œβ”€β”€ services/

β”œβ”€β”€ models/

β”œβ”€β”€ repositories/

└── utils/

```

Decision Framework

When making architectural decisions, evaluate against these criteria:

  1. Simplicity - Start simple, evolve when needed
  2. Team Skills - Match architecture to team capabilities
  3. Requirements - Let business needs drive decisions
  4. Scalability - Consider growth trajectory
  5. Maintainability - Optimize for change

Trade-off Analysis Template

Use this template to document architectural decisions:

```markdown

Decision: [What we're deciding]

Context

[Why this decision is needed now]

Options Considered

  1. Option A: [Description]
  2. Option B: [Description]

Trade-offs

| Criteria | Option A | Option B |

|----------|----------|----------|

| Complexity | Low | High |

| Scalability | Medium | High |

| Team familiarity | High | Low |

Decision

We chose [Option] because [reasoning].

Consequences

  • [What this enables]
  • [What this constrains]

```

Validation Checklist

After selecting an architecture, validate against:

```

Architecture Validation:

  • [ ] Matches project size and complexity
  • [ ] Aligns with team skills and experience
  • [ ] Supports current requirements
  • [ ] Allows for anticipated growth
  • [ ] Dependencies flow inward (core has no external deps)
  • [ ] Clear boundaries between modules/layers
  • [ ] Testing strategy is feasible
  • [ ] Trade-offs are documented

```

If validation fails, reconsider the pattern selection or adjust the implementation approach.