Architecture General
Architecture decisions: layering, design patterns, microservices trade-offs, and domain-driven design
Install
$ agentstack add skill-ucdavis-ai-skills-registry-architecture-general ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Links to your public security report.[](https://agentstack.voostack.com/security/report/skill-ucdavis-ai-skills-registry-architecture-general) Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Architecture — General
Layering
- Separate concerns: presentation → application (use cases) → domain → infrastructure.
- Dependencies flow inward only — domain has no external dependencies.
- Never import infrastructure code from domain or application layers.
- Thin controllers: route, validate, delegate to use case, return response.
Design Patterns
| Pattern | When to use | |---------|-------------| | Repository | Abstract data access — business logic never queries DB directly | | Factory | Complex object initialization with many dependencies | | Strategy | Behavior varies by context; avoid long if/else chains | | Observer/Event | Decouple components across bounded contexts | | Adapter | Integrate third-party APIs without coupling domain to them |
Microservices
- Each service owns its data. No shared databases.
- Define API contracts (OpenAPI/gRPC) before implementation.
- Prefer async messaging (queues) for cross-service operations that don't need immediate consistency.
- Design for failure: timeouts, circuit breakers, retries with exponential backoff.
- Avoid distributed monoliths — if services always deploy together, they're a monolith.
Domain-Driven Design
- Identify bounded contexts before defining APIs.
- Use ubiquitous language — code names match business vocabulary.
- Separate aggregates at transactional boundaries, not technical ones.
- Value objects are immutable; entities have identity and mutable state.
Decisions to Document
- What was decided.
- Why — constraints and alternatives considered.
- Consequences — trade-offs accepted.
- Use Architecture Decision Records (ADRs) in
docs/decisions/.
Trade-offs to Consider
- Consistency vs. availability (CAP theorem).
- Build vs. buy for infrastructure components.
- Sync vs. async for cross-service calls.
- Monolith-first vs. microservices for new systems — default to monolith.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: ucdavis
- Source: ucdavis/ai-skills-registry
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.