architecture-patterns

Solid

Architecture validation and patterns for clean architecture, backend structure enforcement, project structure validation, test standards, and context-aware sizing. Use when designing system boundaries, enforcing layered architecture, validating project structure, defining test standards, or choosing the right architecture tier for project scope.

AI & Automation 208 stars 20 forks Updated today MIT

Install

View on GitHub

Quality Score: 88/100

Stars 20%
77
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

<!-- directive-density: intentional (teaches anti-patterns; NEVER markers describe real layering violations, not aspirational guidance) --> # Architecture Patterns Consolidated architecture validation and enforcement patterns covering clean architecture, backend layer separation, project structure conventions, and test standards. Each category has individual rule files in `references/` loaded on-demand. ## Quick Reference | Category | Rules | Impact | When to Use | |----------|-------|--------|-------------| | [Clean Architecture](#clean-architecture) | 3 | HIGH | SOLID principles, hexagonal architecture, ports & adapters, DDD | | [Project Structure](#project-structure) | 2 | HIGH | Folder conventions, nesting depth, import direction, barrel files | | [Backend Layers](#backend-layers) | 3 | HIGH | Router/service/repository separation, DI, file naming | | [Test Standards](#test-standards) | 3 | MEDIUM | AAA pattern, naming conventions, coverage thresholds | | [Right-Sizing](#right-sizing) | 2 | HIGH | Architecture tier selection, over-engineering prevention, context-aware enforcement | **Total: 13 rules across 5 categories** ## Quick Start ```python # Clean Architecture: Dependency Inversion via Protocol class IUserRepository(Protocol): async def get_by_id(self, id: str) -> User | None: ... class UserService: def __init__(self, repo: IUserRepository): self._repo = repo # Depends on abstraction, not concretion # FastAPI DI chain: DB -> Repository -> Se...

Details

Author
yonatangross
Repository
yonatangross/orchestkit
Created
6 months ago
Last Updated
today
Language
TypeScript
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

AI & Automation Listed

architecture

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.

5 Updated 2 days ago
nxtg-ai
AI & Automation Listed

clean-architecture

Structure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.

0 Updated today
renatoxm
AI & Automation Featured

clean-architecture

Structure software around the Dependency Rule: source code dependencies point inward from frameworks to use cases to entities. Use when the user mentions "architecture layers", "dependency rule", "ports and adapters (hexagonal)", "onion architecture", "screaming architecture", "where should business logic go", "decouple from the database", "swap the framework without a rewrite", or "keep business rules independent". Also trigger when deciding which layer code belongs in, isolating core logic from infrastructure, defining module boundaries, or debating whether the framework should call your code or the reverse. Covers component principles, boundaries, and SOLID. For code-level quality, see clean-code. For domain modeling, see domain-driven-design.

1,745 Updated 4 days ago
wondelai