agentsclimarketplace

Clean architecture

Skill giuseppe-trisciuoglio/developer-kit/plugins/developer-kit-typescript/skills/clean-architecture

Modular plugin marketplace for Claude Code and agentic CLIs, with validated, spec-driven skills, agents, commands, and workflows for Java, TypeScript, Python, PHP, AWS, and AI.

Install
npx -y skills add giuseppe-trisciuoglio/developer-kit --skill clean-architecture

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Provides implementation patterns for Clean Architecture, Domain-Driven Design (DDD), and Hexagonal Architecture (Ports & Adapters) in NestJS/TypeScript applications. Use when structuring complex backend systems, designing domain layers with entities/value objects/aggregates, implementing ports and adapters, creating use cases, or refactoring from anemic models to rich domain models with dependency inversion.

SKILL.md

7.9 KB, ~1.5k tokens by cl100k_base, as published. Nobody here has run it

Clean Architecture, DDD & Hexagonal Architecture for NestJS

Overview

This skill provides comprehensive guidance for implementing Clean Architecture, Domain-Driven Design (DDD), and Hexagonal Architecture patterns in NestJS/TypeScript applications. It covers the architectural layers, tactical patterns, and practical implementation examples for building maintainable, testable, and loosely-coupled backend systems.

When to Use

  • Architecting complex NestJS applications with long-term maintainability
  • Refactoring from tightly-coupled MVC to layered architecture
  • Implementing rich domain models with business logic encapsulation
  • Designing testable systems with swappable infrastructure
  • Creating microservices with clear bounded contexts
  • Separating business rules from framework code
  • Implementing event-driven architectures with domain events

Instructions

1. Understand the Architectural Layers

Clean Architecture organizes code into concentric layers where dependencies flow inward. Inner layers have no knowledge of outer layers:

+-------------------------------------+
|  Infrastructure (Frameworks, DB)    |  Outer layer - volatile
+-------------------------------------+
|  Adapters (Controllers, Repositories)|  Interface adapters
+-------------------------------------+
|  Application (Use Cases)            |  Business rules
+-------------------------------------+
|  Domain (Entities, Value Objects)   |  Core - most stable
+-------------------------------------+

The Hexagonal Architecture (Ports & Adapters) pattern complements this:

  • Ports: Interfaces defining what the application needs
  • Adapters: Concrete implementations of ports
  • Domain Core: Pure business logic with zero dependencies

2. Learn DDD Tactical Patterns

Apply these patterns in your domain layer:

  • Entities: Objects with identity and lifecycle
  • Value Objects: Immutable, defined by attributes
  • Aggregates: Consistency boundaries with aggregate roots
  • Domain Events: Capture state changes
  • Repositories: Abstract data access for aggregates

3. Organize Your Project Structure

Structure your NestJS project following Clean Architecture principles:

src/
+-- domain/                    # Inner layer - no external deps
|   +-- entities/              # Domain entities
|   +-- value-objects/         # Immutable value objects
|   +-- aggregates/            # Aggregate roots
|   +-- events/                # Domain events
|   +-- repositories/          # Repository interfaces (ports)
|   +-- services/              # Domain services
+-- application/               # Use cases - orchestration
|   +-- use-cases/             # Individual use cases
|   +-- ports/                 # Input/output ports
|   +-- dto/                   # Application DTOs
|   +-- services/              # Application services
+-- infrastructure/            # External concerns
|   +-- database/              # ORM config, migrations
|   +-- http/                  # HTTP clients
|   +-- messaging/             # Message queues
+-- adapters/                  # Interface adapters
    +-- http/                  # Controllers, presenters
    +-- persistence/           # Repository implementations
    +-- external/              # External service adapters

4. Implement the Domain Layer

Create pure domain objects with no external dependencies:

  1. Value Objects: Immutable objects validated at construction
  2. Entities: Objects with identity containing business logic
  3. Aggregates: Consistency boundaries protecting invariants
  4. Repository Ports: Interfaces defining data access contracts

5. Implement the Application Layer

Create use cases that orchestrate business logic:

  1. Define input/output DTOs for each use case
  2. Inject repository ports via constructor
  3. Implement business workflows in the execute method
  4. Keep use cases focused on a single responsibility

6. Implement Adapters

Create concrete implementations of ports:

  1. Persistence Adapters: Map domain objects to/from ORM entities
  2. HTTP Adapters: Controllers that transform requests to use case inputs
  3. External Service Adapters: Integrate with third-party services

7. Configure Dependency Injection

Wire everything together in NestJS modules:

  1. Register use cases as providers
  2. Provide repository implementations using interface tokens
  3. Import required infrastructure modules (TypeORM, etc.)

8. Apply Best Practices

Follow these principles throughout implementation:

  1. Dependency Rule: Dependencies only point inward. Domain knows nothing about NestJS, TypeORM, or HTTP.
  2. Rich Domain Models: Put business logic in entities, not services. Avoid anemic domain models.
  3. Immutability: Value objects must be immutable. Create new instances instead of modifying.
  4. Interface Segregation: Keep repository interfaces small and focused.
  5. Constructor Injection: Use NestJS DI in outer layers only. Domain entities use plain constructors.
  6. Validation: Validate at boundaries (DTOs) and enforce invariants in domain.
  7. Testing: Domain layer tests require no NestJS testing module - pure unit tests.
  8. Transactions: Keep transactions in the application layer, not domain.

Examples

For detailed code examples covering all aspects of Clean Architecture implementation, see:

  • references/examples.md - Complete examples including:
    • Value Objects (Email, Money)
    • Entities with Business Logic (OrderItem)
    • Aggregate Roots with Domain Events (Order)
    • Repository Ports (Interfaces)
    • Use Cases (Application Layer)
    • Repository Adapters (Infrastructure)
    • Controller Adapters (HTTP)
    • Module Configuration (DI setup)

Best Practices

For comprehensive guidance on Clean Architecture best practices, including:

  • Core Principles: Dependency Rule, Rich Domain Models, Immutability, Interface Segregation
  • Testing Strategies: Unit testing domain, integration testing application, E2E testing adapters
  • Performance Considerations: Aggregate design, caching strategy, lazy loading

See references/best-practices.md

Constraints and Warnings

Important constraints, common pitfalls, and implementation warnings:

  • Architecture Constraints: Dependency rule violations, domain purity requirements, interface location rules
  • Common Pitfalls: Leaky abstractions, anemic domain models, wrong layer dependencies, missing ports
  • Implementation Warnings: Mapping overhead, learning curve, boilerplate code, transaction boundaries
  • Performance Considerations: Aggregate size, database queries, caching strategies

See references/constraints.md

Quick Start

  1. Read the architectural layers overview above
  2. Review the examples.md for implementation patterns
  3. Study best-practices.md for core principles
  4. Check constraints.md to avoid common pitfalls
  5. Start implementing your domain layer with pure TypeScript classes
  6. Add application layer use cases to orchestrate business logic
  7. Implement adapters for infrastructure concerns
  8. Configure dependency injection in NestJS modules

References

  • references/examples.md - Complete code examples for all layers
  • references/best-practices.md - Comprehensive best practices and principles
  • references/constraints.md - Constraints, pitfalls, and warnings

Gives 0 of the 12 instructions most architecture codebase skills give in ~1.5k tokens

Counted across 811 of the 1,134 authors here whose files we hold, read 2026-08-06

  • ask the user which candidate to explorein 46 of 811, across 16 files
  • apply the deletion test to suspected shallow modulesin 43 of 811, across 15 files
  • read any relevant architecture decision records firstin 31 of 811, across 7 files
  • use exact glossary terms in every suggestionin 29 of 811, across 9 files
  • accept dependencies instead of creating themin 24 of 811, across 5 files
  • include before and after visualisations for each candidatein 24 of 811, across 5 files
  • read the domain glossary before exploringin 24 of 811, across 6 files
  • return results instead of producing side effectsin 23 of 811, across 4 files
  • explore the codebase for shallow modules and frictionin 23 of 811, across 3 files
  • introduce seams only where things varyin 22 of 811, across 3 files
  • reduce the number of methodsin 21 of 811, across 2 files
  • design deep modules with small interfacesin 21 of 811, across 2 files

Said here and by no other author read

  • encapsulate business logic inside rich domain entities
  • inject repository ports via use case constructors
  • map domain objects inside persistence adapters
  • register use cases as providers
  • enforce invariants in the domain layer
  • keep transactions inside the application layer

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.