agentleFS
yht-4403yht-4403/jc-agent-skills/clean-architecture/SKILL.md

clean-architecture

Skill1 starsChanged 16 days agoMITView on GitHub

Provides implementation patterns for Clean Architecture, Hexagonal Architecture (Ports & Adapters), and Domain-Driven Design in Java 21+ Spring Boot 3.5+ applications. Use when structuring layered architectures, separating domain logic from frameworks, implementing ports and adapters, creating entities/value objects/aggregates, or refactoring monolithic codebases for testability and maintainability.

28 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use convention-learner, opentelemetry and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • codewithmukeshSkill

    convention-learner

    Detects and enforces project-specific coding conventions by analyzing existing codebase patterns. Learns naming conventions, folder structure, test organization, and coding style from the existing code. Load when: "conventions", "coding standards", "project patterns", "enforce style", "detect patterns", "learn conventions", "code consistency".

    Also in 3 projects that use this

  • codewithmukeshSkill

    opentelemetry

    OpenTelemetry observability for .NET 10 applications. Covers traces, metrics, and logs using the OpenTelemetry SDK with OTLP export. Includes custom ActivitySource, IMeterFactory metrics, resource configuration, and Aspire Dashboard integration. Load this skill when setting up distributed tracing, custom metrics, OTLP export, or when the user mentions "OpenTelemetry", "OTLP", "traces", "spans", "Activity", "ActivitySource", "metrics", "IMeterFactory", "Meter", "Counter", "Histogram", "Gauge", "telemetry", "observability", "distributed tracing", "OTEL", or "Aspire Dashboard".

    Also in 3 projects that use this

  • MovGP0Skill

    modern-csharp

    Modern C# style guidance for Bendex and MicroSea code changes, including primary constructors, expression-bodied members, var usage, target-typed new, lambdas, and pattern matching.

    Also in 3 projects that use this

  • MicrosoftSkill

    resilience

    Apply resilience patterns (retry, backoff, circuit breaking) when writing or reviewing code that makes outbound HTTP/REST calls, database operations, or any I/O that can experience transient failures. Use this skill when: (1) writing new code that calls external services or APIs, (2) reviewing code that uses fetch, HTTP clients, or service-to-service calls, (3) adding queue consumers or workers that interact with remote systems, (4) debugging intermittent failures in production.

    Also in 3 projects that use this

  • hongyuancSkill

    vertical-slice

    Build and evaluate a production-quality vertical slice before advancing from Pre-Production to Production.

    Also in 3 projects that use this

  • wpankSkill

    caching

    Caching strategies, invalidation, eviction policies, HTTP caching, distributed caching, and anti-patterns. Use when designing cache layers, choosing eviction policies, debugging stale data, or optimizing read-heavy workloads.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

25 rules. 0 are common, 19 are distinctive, and 6 are very specific to this project.

  • 0

    Common

    Most of the 26 edited versions we read keep these.

  • 19

    Distinctive

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow this feature-based package organization:

    line 55
  2. Distinctive:

    Use Java records for immutable value objects with built-in validation

    line 80
  3. Distinctive:

    Place business logic in entities, not services (Rich Domain Model)

    line 81
  4. Distinctive:

    Use strongly-typed IDs to prevent ID confusion

    line 83
  5. Distinctive:

    Use factory methods for entity creation to enforce invariants

    line 85
  6. Very specific:

    Create use case interfaces (driving ports) in application/port/in/

    line 89
  7. Very specific:

    Create external service interfaces (driven ports) in application/port/out/

    line 90
  8. Distinctive:

    Use DTOs for request/response, separate from domain models

    line 92
  9. Very specific:

    Create JPA entities in infrastructure/persistence/

    line 97
  10. Distinctive:

    Use MapStruct or manual mappers for domain-JPA conversion

    line 99
  11. Distinctive:

    Keep infrastructure concerns isolated from domain logic

    line 101
  12. Very specific:

    Create REST controllers in adapter/rest/

    line 105
  13. Distinctive:

    Use Bean Validation on DTOs

    line 107
  14. Distinctive:

    Immutable Value Objects: Use Java records for value objects with built-in validation

    line 114
  15. Distinctive:

    Rich Domain Models: Place business logic in entities, not services

    line 115
  16. Distinctive:

    Transaction Boundaries: Place @Transactional in application services

    line 120
  17. Distinctive:

    Immutable Value Objects: Use Java records for value objects with built-in validation in compact constructors

    line 359
  18. Distinctive:

    Rich Domain Models: Place business logic in entities, not services - avoid anemic domain models

    line 360
  19. Distinctive:

    Transaction Boundaries: Place @Transactional in application services, never in domain layer

    line 365
  20. Very specific:

    Factory Methods: Use static factory methods like Entity.create() for entity construction with invariant enforcement

    line 366
  21. Distinctive:

    Separate JPA Entities: Keep domain entities separate from JPA entities with mappers between them

    line 367
  22. Very specific:

    Domain Layer Purity: Never add Spring annotations (@Entity, @Autowired, @Component) to domain classes

    line 373
  23. Distinctive:

    Framework Isolation: All framework-specific code must stay in infrastructure and adapter layers

    line 375
  24. Distinctive:

    Use read-only transactions for query operations

    line 390
  25. Distinctive:

    Consider CQRS for complex read/write scenarios

    line 391

“Common” is measured: kept by at least 6 in 10 of the 26 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Clean Architecture, Hexagonal Architecture & DDD for Spring Boot

Overview

This skill provides comprehensive guidance for implementing Clean Architecture, Hexagonal Architecture (Ports & Adapters), and Domain-Driven Design tactical patterns in Java 21+ Spring Boot 3.5+ applications. It ensures clear separation of concerns, framework-independent domain logic, and highly testable codebases through proper layering and dependency management.

When to Use

  • Architecting new Spring Boot applications with clear separation of concerns
  • Refactoring tightly coupled code into testable, layered architectures
  • Implementing domain logic independent of frameworks and infrastructure
  • Designing ports and adapters for swappable implementations
  • Applying Domain-Driven Design tactical patterns (entities, value objects, aggregates)
  • Creating testable business logic without Spring context dependencies
  • Trigger phrases: "implement clean architecture", "ports and adapters pattern", "separate domain from infrastructure", "hexagonal architecture Spring Boot", "DDD aggregate design"

Instructions

1. Understand the Core Concepts

Clean Architecture Layers (Dependency Rule)

Dependencies flow inward. Inner layers know nothing about outer layers.

LayerResponsibilitySpring Boot Equivalent
DomainEntities, value objects, domain events, repository interfacesdomain/ - no Spring annotations
ApplicationUse cases, application services, DTOs, portsapplication/ - @Service, @Transactional
InfrastructureFrameworks, database, external APIsinfrastructure/ - @Repository, @Entity
AdapterControllers, presenters, external gatewaysadapter/ - @RestController

Hexagonal Architecture (Ports & Adapters)

  • Domain Core: Pure Java business logic, no framework dependencies
  • Ports: Interfaces defining contracts (driven and driving)
  • Adapters: Concrete implementations (JPA, REST, messaging)

Domain-Driven Design Tactical Patterns

  • Entities: Objects with identity and lifecycle (e.g., Order, Customer)
  • Value Objects: Immutable, defined by attributes (e.g., Money, Email)
  • Aggregates: Consistency boundary with root entity
  • Domain Events: Capture significant business occurrences
  • Repositories: Persistence abstraction, implemented in infrastructure

2. Organize Package Structure

Follow this feature-based package organization:

com.example.order/
├── domain/
│   ├── model/              # Entities, value objects
│   ├── event/              # Domain events
│   ├── repository/         # Repository interfaces (ports)
│   └── exception/          # Domain exceptions
├── application/
│   ├── port/in/            # Driving ports (use case interfaces)
│   ├── port/out/           # Driven ports (external service interfaces)
│   ├── service/            # Application services
│   └── dto/                # Request/response DTOs
├── infrastructure/
│   ├── persistence/        # JPA entities, repository adapters
│   └── external/           # External service adapters
└── adapter/
    └── rest/               # REST controllers

3. Implement the Domain Layer (Framework-Free)

The domain layer must have zero dependencies on Spring or any framework.

  • Use Java records for immutable value objects with built-in validation
  • Place business logic in entities, not services (Rich Domain Model)
  • Define repository interfaces (ports) in the domain layer
  • Use strongly-typed IDs to prevent ID confusion
  • Implement domain events for decoupling side effects
  • Use factory methods for entity creation to enforce invariants

4. Implement the Application Layer

  • Create use case interfaces (driving ports) in application/port/in/
  • Create external service interfaces (driven ports) in application/port/out/
  • Implement application services with @Service and @Transactional
  • Use DTOs for request/response, separate from domain models
  • Publish domain events after successful operations

5. Implement the Infrastructure Layer (Adapters)

  • Create JPA entities in infrastructure/persistence/
  • Implement repository adapters that map between domain and JPA entities
  • Use MapStruct or manual mappers for domain-JPA conversion
  • Configure conditional beans for swappable implementations
  • Keep infrastructure concerns isolated from domain logic

6. Implement the Adapter Layer (REST)

  • Create REST controllers in adapter/rest/
  • Inject use case interfaces, not implementations
  • Use Bean Validation on DTOs
  • Return proper HTTP status codes and responses
  • Handle exceptions with global exception handlers

7. Apply Best Practices

  1. Dependency Rule: Domain has zero dependencies on Spring or other frameworks
  2. Immutable Value Objects: Use Java records for value objects with built-in validation
  3. Rich Domain Models: Place business logic in entities, not services
  4. Repository Pattern: Domain defines interface, infrastructure implements
  5. Domain Events: Decouple side effects from primary operations
  6. Constructor Injection: Mandatory dependencies via final fields
  7. DTO Mapping: Separate domain models from API contracts
  8. Transaction Boundaries: Place @Transactional in application services

8. Write Tests

  • Domain Tests: Pure unit tests without Spring context, fast execution
  • Application Tests: Unit tests with mocked ports using Mockito
  • Infrastructure Tests: Integration tests with @DataJpaTest and Testcontainers
  • Adapter Tests: Controller tests with @WebMvcTest

Examples

Example 1: Domain Layer - Entity with Domain Events

// domain/model/Order.java
public class Order {
    private final OrderId id;
    private final List<OrderItem> items;
    private Money total;
    private OrderStatus status;
    private final List<DomainEvent> domainEvents = new ArrayList<>();

    private Order(OrderId id, List<OrderItem> items) {
        this.id = id;
        this.items = new ArrayList<>(items);
        this.status = OrderStatus.PENDING;
        calculateTotal();
    }

    public static Order create(List<OrderItem> items) {
        validateItems(items);
        Order order = new Order(OrderId.generate(), items);
        order.domainEvents.add(new OrderCreatedEvent(order.id, order.total));
        return order;
    }

    public void confirm() {
        if (status != OrderStatus.PENDING) {
            throw new DomainException("Only pending orders can be confirmed");
        }
        this.status = OrderStatus.CONFIRMED;
    }

    public List<DomainEvent> getDomainEvents() {
        return List.copyOf(domainEvents);
    }

    public void clearDomainEvents() {
        domainEvents.clear();
    }
}

Example 2: Domain Layer - Value Object with Validation

// domain/model/Money.java (Value Object)
public record Money(BigDecimal amount, Currency currency) {
    public Money {
        if (amount.compareTo(BigDecimal.ZERO) < 0) {
            throw new DomainException("Amount cannot be negative");
        }
    }

    public static Money zero() {
        return new Money(BigDecimal.ZERO, Currency.getInstance("EUR"));
    }

    public Money add(Money other) {
        if (!this.currency.equals(other.currency)) {
            throw new DomainException("Currency mismatch");
        }
        return new Money(this.amount.add(other.amount), this.currency);
    }
}

Example 3: Domain Layer - Repository Port

// domain/repository/OrderRepository.java (Port)
public interface OrderRepository {
    Order save(Order order);
    Optional<Order> findById(OrderId id);
}

Example 4: Application Layer - Use Case and Service

// application/port/in/CreateOrderUseCase.java
public interface CreateOrderUseCase {
    OrderResponse createOrder(CreateOrderRequest request);
}

// application/dto/CreateOrderRequest.java
public record CreateOrderRequest(
    @NotNull UUID customerId,
    @NotEmpty List<OrderItemRequest> items
) {}

// application/service/OrderService.java
@Service
@RequiredArgsConstructor
@Transactional
public class OrderService implements CreateOrderUseCase {
    private final OrderRepository orderRepository;
    private final PaymentGateway paymentGateway;
    private final DomainEventPublisher eventPublisher;

    @Override
    public OrderResponse createOrder(CreateOrderRequest request) {
        List<OrderItem> items = mapItems(request.items());
        Order order = Order.create(items);

        PaymentResult payment = paymentGateway.charge(order.getTotal());
        if (!payment.successful()) {
            throw new PaymentFailedException("Payment failed");
        }

        order.confirm();
        Order saved = orderRepository.save(order);
        publishEvents(order);

        return OrderMapper.toResponse(saved);
    }

    private void publishEvents(Order order) {
        order.getDomainEvents().forEach(eventPublisher::publish);
        order.clearDomainEvents();
    }
}

Example 5: Infrastructure Layer - JPA Entity and Adapter

// infrastructure/persistence/OrderJpaEntity.java
@Entity
@Table(name = "orders")
public class OrderJpaEntity {
    @Id
    private UUID id;
    @Enumerated(EnumType.STRING)
    private OrderStatus status;
    private BigDecimal totalAmount;
    @OneToMany(cascade = CascadeType.ALL, orphanRemoval = true)
    private List<OrderItemJpaEntity> items;
}

// infrastructure/persistence/OrderRepositoryAdapter.java
@Component
@RequiredArgsConstructor
public class OrderRepositoryAdapter implements OrderRepository {
    private final OrderJpaRepository jpaRepository;
    private final OrderJpaMapper mapper;

    @Override
    public Order save(Order order) {
        OrderJpaEntity entity = mapper.toEntity(order);
        return mapper.toDomain(jpaRepository.save(entity));
    }

    @Override
    public Optional<Order> findById(OrderId id) {
        return jpaRepository.findById(id.value()).map(mapper::toDomain);
    }
}

Example 6: Adapter Layer - REST Controller

// adapter/rest/OrderController.java
@RestController
@RequestMapping("/api/orders")
@RequiredArgsConstructor
public class OrderController {
    private final CreateOrderUseCase createOrderUseCase;

    @PostMapping
    public ResponseEntity<OrderResponse> createOrder(
            @Valid @RequestBody CreateOrderRequest request) {
        OrderResponse response = createOrderUseCase.createOrder(request);
        URI location = ServletUriComponentsBuilder
            .fromCurrentRequest()
            .path("/{id}")
            .buildAndExpand(response.id())
            .toUri();
        return ResponseEntity.created(location).body(response);
    }
}

Example 7: Domain Tests (No Spring Context)

class OrderTest {
    @Test
    void shouldCreateOrderWithValidItems() {
        List<OrderItem> items = List.of(
            new OrderItem(new ProductId(UUID.randomUUID()), 2, new Money("10.00", EUR))
        );

        Order order = Order.create(items);

        assertThat(order.getStatus()).isEqualTo(OrderStatus.PENDING);
        assertThat(order.getDomainEvents()).hasSize(1);
    }
}

Example 8: Application Tests (Unit with Mocks)

@ExtendWith(MockitoExtension.class)
class OrderServiceTest {
    @Mock OrderRepository orderRepository;
    @Mock PaymentGateway paymentGateway;
    @Mock DomainEventPublisher eventPublisher;

    @InjectMocks OrderService orderService;

    @Test
    void shouldCreateAndConfirmOrder() {
        when(paymentGateway.charge(any())).thenReturn(new PaymentResult(true, "tx-123"));
        when(orderRepository.save(any())).thenAnswer(i -> i.getArgument(0));

        OrderResponse response = orderService.createOrder(createRequest());

        assertThat(response.status()).isEqualTo(OrderStatus.CONFIRMED);
        verify(eventPublisher).publish(any(OrderCreatedEvent.class));
    }
}

Best Practices

  1. Dependency Rule: Domain has zero dependencies on Spring or other frameworks - this is the most critical principle
  2. Immutable Value Objects: Use Java records for value objects with built-in validation in compact constructors
  3. Rich Domain Models: Place business logic in entities, not services - avoid anemic domain models
  4. Repository Pattern: Domain defines interface, infrastructure implements - never the reverse
  5. Domain Events: Decouple side effects from primary operations using event-driven patterns
  6. Constructor Injection: Mandatory dependencies via final fields with Lombok @RequiredArgsConstructor
  7. DTO Mapping: Separate domain models from API contracts - never expose entities directly
  8. Transaction Boundaries: Place @Transactional in application services, never in domain layer
  9. Factory Methods: Use static factory methods like Entity.create() for entity construction with invariant enforcement
  10. Separate JPA Entities: Keep domain entities separate from JPA entities with mappers between them

Constraints and Warnings

Critical Constraints

  • Domain Layer Purity: Never add Spring annotations (@Entity, @Autowired, @Component) to domain classes
  • Dependency Direction: Dependencies must only point inward (domain <- application <- infrastructure/adapter)
  • Framework Isolation: All framework-specific code must stay in infrastructure and adapter layers

Common Pitfalls to Avoid

  • Anemic Domain Model: Entities with only getters/setters, logic in services - place business logic in entities
  • Framework Leakage: @Entity, @Autowired in domain layer - keep domain framework-free
  • Lazy Loading Issues: Exposing JPA entities through domain model - use mappers to convert
  • Circular Dependencies: Between domain aggregates - use IDs instead of direct references
  • Missing Domain Events: Direct service calls instead of events for cross-aggregate communication
  • Repository Misplacement: Defining repository interfaces in infrastructure - they belong in domain
  • DTO Bypass: Exposing domain entities directly in API - always use DTOs for external contracts

Performance Considerations

  • Separate JPA entities from domain models to avoid lazy loading issues
  • Use read-only transactions for query operations
  • Consider CQRS for complex read/write scenarios

References

  • references/java-clean-architecture.md - Java-specific patterns (records, sealed classes, strongly-typed IDs)
  • references/spring-boot-implementation.md - Spring Boot integration (DI patterns, JPA mapping, transaction management)

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.