home / skills / dasien / claudemultiagenttemplate / architecture-patterns

architecture-patterns skill

/templates/.claude/skills/architecture-patterns

This skill helps design maintainable architectures by selecting patterns, defining component boundaries, and planning integration for scalable systems.

npx playbooks add skill dasien/claudemultiagenttemplate --skill architecture-patterns

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.7 KB
---
name: "System Architecture Patterns"
description: "Apply proven architectural patterns (MVC, layered, microservices) to create maintainable systems with clear separation of concerns"
category: "architecture"
required_tools: ["Read", "Write", "Grep", "Glob"]
---

# System Architecture Patterns

## Purpose
Apply proven architectural patterns to create maintainable, scalable systems with clear separation of concerns and well-defined component responsibilities.

## When to Use
- Designing new systems or major features
- Refactoring existing architecture
- Solving common architectural challenges
- Organizing complex codebases

## Key Capabilities
1. **Pattern Selection** - Choose appropriate patterns for the problem
2. **Component Design** - Define clear boundaries and responsibilities
3. **Integration Planning** - Design how components communicate

## Approach
1. Understand the problem domain and requirements
2. Identify architectural concerns (scalability, maintainability, etc.)
3. Select patterns that address those concerns
4. Define component boundaries and interfaces
5. Document pattern application and rationale

## Example
**Context**: Web application with business logic and data access

**Pattern**: Layered Architecture
````
Presentation Layer (UI)
    ↓
Business Logic Layer (Services)
    ↓
Data Access Layer (Repositories)
    ↓
Database
````

**Benefits**:
- Clear separation of concerns
- Easy to test each layer independently
- Can swap implementations (e.g., different databases)

## Best Practices
- ✅ Choose patterns that solve actual problems
- ✅ Document why you chose each pattern
- ✅ Keep it simple - don't over-architect
- ❌ Avoid: Using patterns just because they're popular

Overview

This skill applies proven system architecture patterns (MVC, layered, microservices, etc.) to design maintainable, scalable software with clear separation of concerns. It helps teams pick patterns that match domain requirements and document component responsibilities. The goal is pragmatic, testable architectures that reduce coupling and ease evolution.

How this skill works

I analyze the problem domain, nonfunctional requirements (scalability, reliability, deployability) and team constraints, then recommend one or more architectural patterns and define component boundaries. I produce integration plans that specify interfaces, communication styles, and data flow, plus rationale and trade-offs for the chosen pattern. Deliverables include concise diagrams, component responsibilities, and migration or refactor steps if needed.

When to use it

  • Designing a new system or major feature where long-term maintainability matters
  • Refactoring an existing codebase to reduce coupling or improve testability
  • Choosing how to split services and responsibilities in a distributed system
  • Defining interfaces and ownership for multi-team development
  • Evaluating trade-offs for scalability, deployment, or operational complexity

Best practices

  • Match pattern to concrete problems; avoid applying patterns by trend alone
  • Document why a pattern was chosen, its boundaries, and expected evolution
  • Keep layers and services small and focused; prefer simplicity over premature optimization
  • Define clear interfaces and contracts for integrations up front
  • Include migration and rollback plans when introducing new architectural boundaries

Example use cases

  • Convert a monolith into modular layers (presentation, services, repositories) to enable independent testing and swapping persistence implementations
  • Design a microservices split for a growing product, including API gateways, service contracts, and data ownership rules
  • Apply MVC or component-based patterns for a web UI backed by a clean service layer and repository pattern
  • Create an integration plan for hybrid architectures where some modules remain monolithic while others move to services

FAQ

How do I choose between layered architecture and microservices?

Start with requirements: layered suits moderate complexity and smaller teams; microservices fit large, independent teams with need for independent deployability. Consider operational overhead and data consistency needs.

What documentation should I produce when recommending a pattern?

Provide a short rationale, component diagram, interface contracts, data ownership map, and steps for implementation or migration. Include tests and monitoring expectations.