Stats
Actions
Tags
From framework-dev
Use this skill during Phase 2 (Structure) to select appropriate architecture patterns. Covers MVC, Hexagonal, Clean Architecture, Microservices, and provides decision criteria for each.
How this skill is triggered — by the user, by Claude, or both
Slash command
/framework-dev:architecture-patternsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill guides the selection of appropriate architecture patterns during Phase 2, providing decision criteria, trade-offs, and implementation guidance.
This skill guides the selection of appropriate architecture patterns during Phase 2, providing decision criteria, trade-offs, and implementation guidance.
| Pattern | Best For | Team Size | Complexity | Scalability |
|---|---|---|---|---|
| MVC | Simple CRUD apps | 1-3 | Low | Medium |
| Layered | Traditional enterprise | 3-10 | Medium | Medium |
| Hexagonal | Domain-focused apps | 3-15 | Medium-High | High |
| Clean | Complex business logic | 5-20 | High | High |
| Microservices | Large distributed systems | 10+ | Very High | Very High |
| Modular Monolith | Growing apps, unclear boundaries | 3-10 | Medium | Medium-High |
┌─────────────────────────────────────┐
│ Controller │
│ (Handles requests, routes) │
└────────────┬───────────┬────────────┘
│ │
▼ ▼
┌──────────┐ ┌──────────┐
│ Model │ │ View │
│ (Data) │ │ (UI) │
└──────────┘ └──────────┘
When to Use:
Pros:
Cons:
Example Structure:
src/
├── controllers/
│ ├── userController.ts
│ └── taskController.ts
├── models/
│ ├── User.ts
│ └── Task.ts
└── views/
└── (templates or React components)
┌─────────────────────────────────────┐
│ Presentation Layer │
│ (Controllers, Views, DTOs) │
└─────────────────┬───────────────────┘
│
┌─────────────────▼───────────────────┐
│ Business Layer │
│ (Services, Domain Logic) │
└─────────────────┬───────────────────┘
│
┌─────────────────▼───────────────────┐
│ Data Access Layer │
│ (Repositories, ORM) │
└─────────────────┬───────────────────┘
│
┌─────────────────▼───────────────────┐
│ Database │
└─────────────────────────────────────┘
When to Use:
Pros:
Cons:
┌─────────────────┐
│ REST API │
│ (Adapter) │
└────────┬────────┘
│
┌─────────────┐ ┌─────────▼─────────┐ ┌─────────────┐
│ CLI │◄───│ │───►│ PostgreSQL │
│ (Adapter) │ │ DOMAIN CORE │ │ (Adapter) │
└─────────────┘ │ │ └─────────────┘
│ (Business │
┌─────────────┐ │ Logic) │ ┌─────────────┐
│ Message │◄───│ │───►│ Redis │
│ Queue │ │ [Ports define │ │ (Adapter) │
│ (Adapter) │ │ interfaces] │ └─────────────┘
└─────────────┘ └───────────────────┘
When to Use:
Pros:
Cons:
Example Structure:
src/
├── domain/ # Core business logic
│ ├── entities/
│ │ └── User.ts
│ ├── services/
│ │ └── UserService.ts
│ └── ports/ # Interfaces
│ ├── UserRepository.ts
│ └── NotificationService.ts
├── adapters/
│ ├── primary/ # Driving adapters
│ │ ├── rest/
│ │ │ └── UserController.ts
│ │ └── cli/
│ └── secondary/ # Driven adapters
│ ├── persistence/
│ │ └── PostgresUserRepository.ts
│ └── notification/
│ └── EmailNotificationService.ts
└── config/
└── dependencies.ts # Dependency injection
┌─────────────────────────────────────────────┐
│ Frameworks & Drivers │
│ (Web, DB, External Interfaces) │
│ ┌───────────────────────────────────────┐ │
│ │ Interface Adapters │ │
│ │ (Controllers, Presenters, Gateways) │ │
│ │ ┌─────────────────────────────────┐ │ │
│ │ │ Application Business │ │ │
│ │ │ (Use Cases) │ │ │
│ │ │ ┌───────────────────────────┐ │ │ │
│ │ │ │ Enterprise Business │ │ │ │
│ │ │ │ (Entities) │ │ │ │
│ │ │ └───────────────────────────┘ │ │ │
│ │ └─────────────────────────────────┘ │ │
│ └───────────────────────────────────────┘ │
└─────────────────────────────────────────────┘
Dependencies point INWARD only.
When to Use:
Pros:
Cons:
┌──────────┐ ┌──────────┐ ┌──────────┐
│ User │ │ Order │ │ Payment │
│ Service │ │ Service │ │ Service │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└──────┬──────┴──────┬──────┘
│ │
┌────▼────┐ ┌────▼────┐
│API GW │ │Event Bus│
└─────────┘ └─────────┘
When to Use:
Pros:
Cons:
When NOT to Use:
┌────────────────────────────────────────┐
│ Single Deployable │
│ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ Users │ │ Orders │ │Payment │ │
│ │ Module │ │ Module │ │ Module │ │
│ │ │ │ │ │ │ │
│ │ ┌──────┐ │ │ ┌──────┐ │ │┌──────┐│ │
│ │ │Domain│ │ │ │Domain│ │ ││Domain││ │
│ │ └──────┘ │ │ └──────┘ │ │└──────┘│ │
│ │ ┌──────┐ │ │ ┌──────┐ │ │┌──────┐│ │
│ │ │ API │ │ │ │ API │ │ ││ API ││ │
│ │ └──────┘ │ │ └──────┘ │ │└──────┘│ │
│ └──────────┘ └──────────┘ └────────┘ │
│ │
│ Shared Infrastructure │
└────────────────────────────────────────┘
When to Use:
Pros:
Cons:
START
│
▼
Is the domain complex?
│
├─ NO → Is it a simple CRUD app?
│ │
│ ├─ YES → MVC
│ └─ NO → Layered Architecture
│
└─ YES → Do you need independent deployments?
│
├─ YES → Do you have 10+ developers?
│ │
│ ├─ YES → Microservices
│ └─ NO → Modular Monolith
│
└─ NO → Need to swap infrastructure easily?
│
├─ YES → Hexagonal
└─ NO → Clean Architecture
For each pattern considered:
### Pattern Research: [Name]
**Official Sources:**
- [URL to authoritative source]
**Pros for Our Project:**
- [Specific benefit]
**Cons for Our Project:**
- [Specific drawback]
**Team Familiarity:** Low | Medium | High
**Verdict:** SUITABLE | NOT SUITABLE | NEEDS DISCUSSION
During Phase 2:
npx claudepluginhub ankurjain1121/framework-developer-agentDesigns software architecture and selects appropriate patterns (layered, clean, hexagonal) based on project size and team size. Activate when structuring new projects or making architectural decisions.
Provides decision trees, matrices, and trade-offs for selecting architectural styles like Hexagonal, Microservices, Modular Monolith, and Vertical Slice by domain complexity, team size, and deployment.
Interactively selects and routes to architecture paradigms for new systems via scenario matching, compares trade-offs, creates ADRs, evaluates fit for team size and complexity.