architecturelisted

Clean Architecture, Domain-Driven Design, and backend system-design guidance: organizing a codebase into layers with the right dependency direction, choosing structural design patterns (Repository, Strategy, Observer, Command, DI), applying DDD tactical patterns (entities vs value objects, aggregates), designing REST resources and status codes, persistence (unit-of-work, N+1), caching, domain events, layered error handling, and recording decisions as ADRs. Use when designing a new system or feature, deciding which layer code belongs in, refactoring a tangled/God-object codebase, reviewing coupling and boundaries, shaping an API, or writing an Architecture Decision Record.
nxtg-ai/forge-plugin · ★ 5 · AI & Automation · score 76

Install: claude install-skill nxtg-ai/forge-plugin

# Architecture & System Design **What this skill is**: reusable, language-agnostic guidance for structuring a codebase — Clean Architecture layering, the dependency rule, the structural design patterns that keep boundaries clean, and the ADR format for recording decisions. **What this skill is NOT**: a description of the shipped NXTG-Forge implementation. The real forge repos are polyglot (Rust orchestrator, Node governance MCP, React UI) — for their actual internals read the repo `CLAUDE.md` files, not this skill. The examples below are illustrative reference patterns you apply to *a* project, shown in Python as one concrete language. --- ## Clean Architecture in one rule **Dependencies point inward. Inner layers know nothing about outer layers.** ``` ┌─────────────────────────────────────────────┐ │ Interface (CLI / HTTP / UI) │ ─┐ ├─────────────────────────────────────────────┤ │ │ Infrastructure (files, DB, network, I/O) │ ─┤ imports allowed ├─────────────────────────────────────────────┤ │ in this direction ▼ │ Application (use cases, orchestration) │ ─┤ ├─────────────────────────────────────────────┤ │ │ Domain (entities, value objects, rules) │ ◄┘ imports nothing outward └─────────────────────────────────────────────┘ ``` The payoff: business rules survive a CLI rewrite, a DB swap, or a UI change, because none of those outer things are imported by the domain. The domain is testable with no mocks because it has no I/O.