# architecture-patterns

> Common architecture patterns and system design principles. Use when making architectural decisions or designing new features.

- Author: erik1908
- Repository: quadero-com/multi-agent-dev-system
- Version: 20260131120238
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-06
- Source: https://github.com/quadero-com/multi-agent-dev-system
- Web: https://mule.run/skillshub/@@quadero-com/multi-agent-dev-system~architecture-patterns:20260131120238

---

---
name: architecture-patterns
description: Common architecture patterns and system design principles. Use when making architectural decisions or designing new features.
---

# Architecture Patterns

## Layered Architecture

```
┌─────────────────────────────────┐
│       Presentation Layer        │  ← API routes, controllers
├─────────────────────────────────┤
│       Application Layer         │  ← Use cases, business logic
├─────────────────────────────────┤
│         Domain Layer            │  ← Entities, domain services
├─────────────────────────────────┤
│      Infrastructure Layer       │  ← Database, external APIs
└─────────────────────────────────┘
```

## Key Patterns

### Repository Pattern
- Abstract data access behind interfaces
- Enable testing with in-memory implementations
- Support multiple data sources

### Service Pattern
- Encapsulate business logic
- Keep controllers thin
- Single responsibility per service

### Dependency Injection
- Define dependencies as interfaces
- Inject at construction time
- Enable testing and flexibility

## Decision Criteria

When choosing patterns, consider:
1. **Simplicity**: Is this the simplest solution?
2. **Testability**: Can we test this easily?
3. **Flexibility**: Can we change this later?
4. **Performance**: Does this meet our needs?

## Anti-Patterns to Avoid

- God objects (classes that do everything)
- Tight coupling between layers
- Business logic in controllers
- Direct database access from handlers