Architecture Patterns
Structure a growing codebase with Clean Architecture, Hexagonal ports/adapters, and DDD tactical patterns so agents do not entangle frameworks with domain logic.
Overview
Architecture Patterns is an agent skill most often used in Build (also Validate) that implements Clean Architecture, Hexagonal, and DDD patterns with checklists and sample structure—not framework tutorials.
Install
npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill architecture-patternsWhat is this skill?
- Clean Architecture layers: entities, use cases, interface adapters, frameworks—with inward dependency rule
- Hexagonal ports and adapters for swappable DB, REST, and message-queue implementations
- DDD strategic patterns: bounded contexts, context mapping, ubiquitous language
- DDD tactical patterns: entities, value objects, aggregates, repositories, domain events
- Directory structure and checklist-style implementation guidance referenced in the playbook file
- 3 architecture families documented: Clean, Hexagonal, DDD
- 4 Clean Architecture layers enumerated in the playbook
Adoption & trust: 644 installs on skills.sh; 40.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent keeps putting SQL and HTTP calls inside route handlers, so every feature becomes untestable and locked to one stack.
Who is it for?
Indie backends scaling past MVP who want opinionated structure without hiring a platform team.
Skip if: Throwaway prototypes, single-file scripts, or teams already standardized on one official framework template they will not deviate from.
When should I use this skill?
You are designing or refactoring backend structure and need Clean, Hexagonal, or DDD patterns applied with concrete folder guidance.
What do I get? / Deliverables
You get a layer- and context-aware folder plan with ports, adapters, and domain models that separate business rules from frameworks.
- Recommended directory structure aligned to chosen pattern
- Port/adapter boundaries for infrastructure
- DDD-oriented module map (contexts, aggregates, repositories)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Build is the primary shelf for implementing layers, folders, and repositories; the same playbook helps during Validate when scoping bounded contexts before code exists. Backend subphase fits domain cores, use cases, repositories, and API adapters—the main content of the playbook.
Where it fits
Define two bounded contexts (billing vs catalog) before committing to microservices vs monolith folders.
Scaffold entities and use cases with adapters for Postgres and Stripe webhooks.
Add a message-queue adapter behind a port without importing SDK types into domain code.
Check a PR for inward dependencies violated by framework imports in the entity layer.
How it compares
Structural pattern playbook—lighter than a full platform scaffold generator, heavier than a lint-only review skill.
Common Questions / FAQ
Who is architecture-patterns for?
Solo and indie builders shipping APIs or SaaS backends who need the agent to follow Clean/Hexagonal/DDD vocabulary consistently.
When should I use architecture-patterns?
In Validate when drawing bounded contexts and ubiquitous language; in Build when creating directory layout, use cases, and repository ports; before major refactors that touch domain logic.
Is architecture-patterns safe to install?
It supplies design guidance only; review the Security Audits panel on this Prism page and apply patterns manually in your repo.
SKILL.md
READMESKILL.md - Architecture Patterns
# Architecture Patterns Implementation Playbook This file contains detailed patterns, checklists, and code samples referenced by the skill. ## Core Concepts ### 1. Clean Architecture (Uncle Bob) **Layers (dependency flows inward):** - **Entities**: Core business models - **Use Cases**: Application business rules - **Interface Adapters**: Controllers, presenters, gateways - **Frameworks & Drivers**: UI, database, external services **Key Principles:** - Dependencies point inward - Inner layers know nothing about outer layers - Business logic independent of frameworks - Testable without UI, database, or external services ### 2. Hexagonal Architecture (Ports and Adapters) **Components:** - **Domain Core**: Business logic - **Ports**: Interfaces defining interactions - **Adapters**: Implementations of ports (database, REST, message queue) **Benefits:** - Swap implementations easily (mock for testing) - Technology-agnostic core - Clear separation of concerns ### 3. Domain-Driven Design (DDD) **Strategic Patterns:** - **Bounded Contexts**: Separate models for different domains - **Context Mapping**: How contexts relate - **Ubiquitous Language**: Shared terminology **Tactical Patterns:** - **Entities**: Objects with identity - **Value Objects**: Immutable objects defined by attributes - **Aggregates**: Consistency boundaries - **Repositories**: Data access abstraction - **Domain Events**: Things that happened ## Clean Architecture Pattern ### Directory Structure ``` app/ ├── domain/ # Entities & business rules │ ├── entities/ │ │ ├── user.py │ │ └── order.py │ ├── value_objects/ │ │ ├── email.py │ │ └── money.py │ └── interfaces/ # Abstract interfaces │ ├── user_repository.py │ └── payment_gateway.py ├── use_cases/ # Application business rules │ ├── create_user.py │ ├── process_order.py │ └── send_notification.py ├── adapters/ # Interface implementations │ ├── repositories/ │ │ ├── postgres_user_repository.py │ │ └── redis_cache_repository.py │ ├── controllers/ │ │ └── user_controller.py │ └── gateways/ │ ├── stripe_payment_gateway.py │ └── sendgrid_email_gateway.py └── infrastructure/ # Framework & external concerns ├── database.py ├── config.py └── logging.py ``` ### Implementation Example ```python # domain/entities/user.py from dataclasses import dataclass from datetime import datetime from typing import Optional @dataclass class User: """Core user entity - no framework dependencies.""" id: str email: str name: str created_at: datetime is_active: bool = True def deactivate(self): """Business rule: deactivating user.""" self.is_active = False def can_place_order(self) -> bool: """Business rule: active users can order.""" return self.is_active # domain/interfaces/user_repository.py from abc import ABC, abstractmethod from typing import Optional, List from domain.entities.user import User class IUserRepository(ABC): """Port: defines contract, no implementation.""" @abstractmethod async def find_by_id(self, user_id: str) -> Optional[User]: pass @abstractmethod async def find_by_email(self, email: str) -> Optional[User]: pass @abstractmethod async def save(self, user: User) -> User: pass @abstractmethod async def delete(self, user_id: str) -> bool: pass # use_cases/create_user.py from domain.entities.user import User from domain.interfaces.user_repository import IUserRepository from dataclasses import dataclass from datetime import datetime import uuid @dataclass class CreateUserRequest: email: str name: str @dataclass class CreateUserResponse: user: User success: bool error: Optional[str] = None class CreateUserUseCase: """Use case: orchestrates business logic.""" def __init__(self, user_repository: IUserRepository): self.use