Backend Patterns
When designing server architecture, database interactions, or API structure. Not for: Frontend logic or simple scripts.
Backend patterns for server architecture, database interactions, and API design.
Core Concept
Backend patterns provide proven solutions for common architectural challenges:
- Server architecture: MVC, Layered architecture, Hexagonal (when justified)
- Database interactions: Repository pattern, Unit of Work, Data Mapper
- API structure: REST, GraphQL, RPC (select based on requirements)
- Security: Authentication, authorization, input validation, output sanitization
Pattern Selection Matrix
| Requirement |
Recommended Pattern |
When to Use |
| Simple CRUD API |
REST + MVC |
Standard web applications |
| Complex business logic |
Layered architecture |
Domain complexity requires isolation |
| Database abstraction |
Repository pattern |
Need testable data access layer |
| Real-time features |
WebSocket + Events |
Live updates, notifications |
| High scalability |
Microservices (justify) |
CLEAR team boundaries, independent deployment |
Best Practices
- Prefer simplicity over enterprise patterns when justified
- Use repository pattern for testable database interactions
- Implement proper error handling and logging
- Validate all input and sanitize all output
- Use environment variables for configuration
- Implement proper authentication and authorization
- Design APIs with clear versioning strategy
- Use appropriate HTTP status codes
- Implement rate limiting for public APIs
Dynamic Sourcing Protocol
CONDITIONAL FETCH: Fetch https://swagger.io/docs/specification/ only when documenting APIs with OpenAPI.
The local skill focuses on Seed System-specific backend patterns.
Navigation
Official Documentation:
Local References:
| If you need... |
Read... |
| Seed System REST patterns |
references/api-patterns.md |
| Database patterns |
references/database-patterns.md |
| Security patterns |
references/security-patterns.md |
Absolute Constraints
NEVER expose database errors directly to clients
NEVER trust client-side validation (server-side validation is mandatory)
NEVER hardcode secrets or credentials in code
Choose patterns based on actual requirements, not theoretical future needs. Start simple, add complexity only when justified.
Genetic Code
This component carries essential Seed System principles for context: fork isolation:
Delta Standard: Good Component = Expert Knowledge − What Claude Already Knows
Recognition Questions:
- "Would Claude know this without being told?" → Delete (zero delta)
- "Can this work standalone?" → Fix if no (non-self-sufficient)
- "Did I read the actual file, or just see it in grep?" → Verify before claiming
1---2name: backend-patterns-43description: Apply backend patterns for server architecture, database interactions, and API structure. Use when designing backend systems. Not for frontend logic or simple scripts.4---5
6# Backend Patterns
7
8<mission_control>
9<objective>Apply backend architecture patterns for server design, database interactions, and API structure</objective>
10<success_criteria>Backend system follows established patterns for scalability, maintainability, and security</success_criteria>
11</mission_control>
12
13<trigger>When designing server architecture, database interactions, or API structure. Not for: Frontend logic or simple scripts.</trigger>
14
15<interaction_schema>
16ANALYZE REQUIREMENTS → SELECT PATTERN → IMPLEMENT → VALIDATE
17</interaction_schema>
18
19Backend patterns for server architecture, database interactions, and API design.
20
21## Core Concept
22
23Backend patterns provide proven solutions for common architectural challenges:
24
25- **Server architecture**: MVC, Layered architecture, Hexagonal (when justified)
26- **Database interactions**: Repository pattern, Unit of Work, Data Mapper
27- **API structure**: REST, GraphQL, RPC (select based on requirements)
28- **Security**: Authentication, authorization, input validation, output sanitization
29
30## Pattern Selection Matrix
31
32| Requirement | Recommended Pattern | When to Use |
33| ---------------------- | ----------------------- | --------------------------------------------- |
34| Simple CRUD API | REST + MVC | Standard web applications |
35| Complex business logic | Layered architecture | Domain complexity requires isolation |
36| Database abstraction | Repository pattern | Need testable data access layer |
37| Real-time features | WebSocket + Events | Live updates, notifications |
38| High scalability | Microservices (justify) | CLEAR team boundaries, independent deployment |
39
40## Best Practices
41
42- Prefer simplicity over enterprise patterns when justified
43- Use repository pattern for testable database interactions
44- Implement proper error handling and logging
45- Validate all input and sanitize all output
46- Use environment variables for configuration
47- Implement proper authentication and authorization
48- Design APIs with clear versioning strategy
49- Use appropriate HTTP status codes
50- Implement rate limiting for public APIs
51
52---
53
54## Dynamic Sourcing Protocol
55
56<fetch_protocol>
57**MANDATORY FETCH**: Before designing REST APIs, fetch the content from:
58
59- https://restfulapi.net/ (REST principles and constraints)
60- https://developer.mozilla.org/en-US/docs/Web/HTTP/Status (HTTP status codes)
61
62**CONDITIONAL FETCH**: Fetch https://swagger.io/docs/specification/ only when documenting APIs with OpenAPI.
63
64The local skill focuses on Seed System-specific backend patterns.
65</fetch_protocol>
66
67---
68
69## Navigation
70
71**Official Documentation**:
72
73- REST API standards → https://restfulapi.net/
74- HTTP status codes → https://developer.mozilla.org/en-US/docs/Web/HTTP/Status
75- OpenAPI specification → https://swagger.io/docs/specification/
76
77**Local References**:
78
79| If you need... | Read... |
80| ------------------------- | ------------------------------- |
81| Seed System REST patterns | references/api-patterns.md |
82| Database patterns | references/database-patterns.md |
83| Security patterns | references/security-patterns.md |
84
85---
86
87## Absolute Constraints
88
89<critical_constraint>
90MANDATORY: Validate all input at API boundaries
91MANDATORY: Sanitize all output to prevent injection attacks
92MANDATORY: Use repository pattern for database access (not inline queries)
93MANDATORY: Implement proper error handling with appropriate status codes
94MANDATORY: Use environment variables for sensitive configuration (never hardcode secrets)
95MANDATORY: Implement rate limiting for public APIs
96
97NEVER expose database errors directly to clients
98NEVER trust client-side validation (server-side validation is mandatory)
99NEVER hardcode secrets or credentials in code
100
101Choose patterns based on actual requirements, not theoretical future needs. Start simple, add complexity only when justified.
102</critical_constraint>
103
104---
105
106## Genetic Code
107
108This component carries essential Seed System principles for context: fork isolation:
109
110<critical_constraint>
111MANDATORY: All components MUST be self-contained (zero .claude/rules dependency)
112MANDATORY: Achieve 80-95% autonomy (0-5 AskUserQuestion rounds per session)
113MANDATORY: Description MUST use What-When-Not format in third person
114MANDATORY: No component references another component by name in description
115MANDATORY: Progressive disclosure - references/ for detailed content
116MANDATORY: Use XML for control (mission_control, critical_constraint), Markdown for data
117No exceptions. Portability invariant must be maintained.
118</critical_constraint>
119
120**Delta Standard**: Good Component = Expert Knowledge − What Claude Already Knows
121
122**Recognition Questions**:
123
124- "Would Claude know this without being told?" → Delete (zero delta)
125- "Can this work standalone?" → Fix if no (non-self-sufficient)
126- "Did I read the actual file, or just see it in grep?" → Verify before claiming
127
128---
majiayu000