acc-clean-arch-knowledge

Clean Architecture knowledge base. Provides patterns, antipatterns, and PHP-specific guidelines for Clean Architecture and Hexagonal Architecture audits.

181 stars

Best use case

acc-clean-arch-knowledge is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Clean Architecture knowledge base. Provides patterns, antipatterns, and PHP-specific guidelines for Clean Architecture and Hexagonal Architecture audits.

Teams using acc-clean-arch-knowledge should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/acc-clean-arch-knowledge/SKILL.md --create-dirs "https://raw.githubusercontent.com/majiayu000/claude-skill-registry/main/skills/data/acc-clean-arch-knowledge/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/acc-clean-arch-knowledge/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How acc-clean-arch-knowledge Compares

Feature / Agentacc-clean-arch-knowledgeStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Clean Architecture knowledge base. Provides patterns, antipatterns, and PHP-specific guidelines for Clean Architecture and Hexagonal Architecture audits.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# Clean Architecture Knowledge Base

Quick reference for Clean Architecture / Hexagonal Architecture patterns and PHP implementation guidelines.

## Core Principles

### The Dependency Rule

```
┌────────────────────────────────────────────────────────────────┐
│                    FRAMEWORKS & DRIVERS                        │
│  (Web, UI, DB, External Services, Devices)                     │
├────────────────────────────────────────────────────────────────┤
│                    INTERFACE ADAPTERS                          │
│  (Controllers, Gateways, Presenters, Repositories)             │
├────────────────────────────────────────────────────────────────┤
│                    APPLICATION BUSINESS RULES                  │
│  (Use Cases, Application Services)                             │
├────────────────────────────────────────────────────────────────┤
│                    ENTERPRISE BUSINESS RULES                   │
│  (Entities, Value Objects, Domain Services)                    │
└────────────────────────────────────────────────────────────────┘
                              ▲
                              │
              Dependencies point INWARD only
```

**Rule:** Source code dependencies must point INWARD. Inner layers know nothing about outer layers.

### Hexagonal Architecture (Ports & Adapters)

```
                    ┌─────────────────┐
                    │   Primary       │
                    │   Adapters      │
                    │  (Controllers)  │
                    └────────┬────────┘
                             │
                             ▼
                    ┌─────────────────┐
        ┌──────────►│     PORTS       │◄──────────┐
        │           │  (Interfaces)   │           │
        │           └────────┬────────┘           │
        │                    │                    │
        │                    ▼                    │
        │           ┌─────────────────┐           │
        │           │   APPLICATION   │           │
        │           │    (Use Cases)  │           │
        │           └────────┬────────┘           │
        │                    │                    │
        │                    ▼                    │
        │           ┌─────────────────┐           │
        │           │     DOMAIN      │           │
        │           │   (Entities)    │           │
        │           └─────────────────┘           │
        │                                         │
        │           ┌─────────────────┐           │
        └───────────│   Secondary     │───────────┘
                    │   Adapters      │
                    │ (Repositories,  │
                    │  External APIs) │
                    └─────────────────┘
```

**Rule:** Application core defines Ports (interfaces). Adapters implement them.

## Quick Checklists

### Domain Layer Checklist

- [ ] No imports from outer layers
- [ ] No framework dependencies
- [ ] Pure business logic
- [ ] Value Objects for concepts
- [ ] Entities with behavior
- [ ] Repository interfaces only

### Application Layer Checklist

- [ ] Use Cases orchestrate domain
- [ ] Defines Ports (interfaces) for external services
- [ ] DTOs for input/output
- [ ] No infrastructure details
- [ ] No framework dependencies

### Interface Adapters Checklist

- [ ] Implements domain/application interfaces
- [ ] Controllers call Use Cases
- [ ] Presenters format output
- [ ] No business logic

### Frameworks & Drivers Checklist

- [ ] Configuration only
- [ ] Wiring/DI setup
- [ ] Framework-specific code isolated

## Common Violations Quick Reference

| Violation | Where to Look | Severity |
|-----------|---------------|----------|
| Inner layer imports outer | Domain/Application importing Infrastructure | Critical |
| Framework in core | Doctrine/Symfony in Domain | Critical |
| Use Case with HTTP details | Request/Response in Application | Critical |
| Business logic in Controller | if/switch on domain state | Warning |
| Missing Port | Direct external service call | Warning |
| Adapter with logic | Repository doing validation | Warning |

## PHP 8.5 Clean Architecture Patterns

### Port (Driven Port)

```php
// Application layer - defines the contract
namespace Application\Order\Port;

interface PaymentGatewayInterface
{
    public function charge(PaymentRequest $request): PaymentResponse;
    public function refund(string $transactionId, Money $amount): RefundResponse;
}
```

### Adapter (Driven Adapter)

```php
// Infrastructure layer - implements the contract
namespace Infrastructure\Payment;

final readonly class StripePaymentGateway implements PaymentGatewayInterface
{
    public function __construct(
        private StripeClient $stripe
    ) {}

    public function charge(PaymentRequest $request): PaymentResponse
    {
        $charge = $this->stripe->charges->create([
            'amount' => $request->amount->cents(),
            'currency' => $request->currency->value,
            'source' => $request->token,
        ]);

        return new PaymentResponse(
            transactionId: $charge->id,
            status: PaymentStatus::from($charge->status)
        );
    }
}
```

### Use Case (Application Service)

```php
namespace Application\Order\UseCase;

final readonly class ProcessPaymentUseCase
{
    public function __construct(
        private OrderRepositoryInterface $orders,
        private PaymentGatewayInterface $paymentGateway,  // Port
        private EventDispatcherInterface $events
    ) {}

    public function execute(ProcessPaymentCommand $command): PaymentResult
    {
        $order = $this->orders->findById($command->orderId);

        $payment = $this->paymentGateway->charge(
            new PaymentRequest($order->total(), $command->paymentToken)
        );

        if ($payment->isSuccessful()) {
            $order->markAsPaid($payment->transactionId());
            $this->orders->save($order);
        }

        return new PaymentResult($payment->transactionId(), $payment->status());
    }
}
```

### Controller (Driving Adapter)

```php
namespace Presentation\Api\Order;

final readonly class PaymentController
{
    public function __construct(
        private ProcessPaymentUseCase $processPayment
    ) {}

    public function process(Request $request): JsonResponse
    {
        $command = new ProcessPaymentCommand(
            orderId: new OrderId($request->get('order_id')),
            paymentToken: $request->get('payment_token')
        );

        $result = $this->processPayment->execute($command);

        return new JsonResponse([
            'transaction_id' => $result->transactionId,
            'status' => $result->status->value,
        ]);
    }
}
```

## References

For detailed information, load these reference files:

- `references/dependency-rule.md` — The Dependency Rule explained
- `references/layer-boundaries.md` — Layer responsibilities and boundaries
- `references/port-adapter-patterns.md` — Hexagonal Architecture patterns
- `references/antipatterns.md` — Common violations with detection patterns

Related Skills

Advanced React Clean Integration

181
from majiayu000/claude-skill-registry

Integrate React with clean architecture without framework leakage using hooks as adapters and presenters. Use when connecting React to domain logic, designing hook-based DI, or isolating UI from business rules.

Advanced Clean Hexagonal Architecture

181
from majiayu000/claude-skill-registry

Apply Clean Architecture and Hexagonal (Ports & Adapters) patterns for domain isolation and testability. Use when designing system boundaries, creating ports/adapters, or structuring domain-driven applications.

advanced-agentdb-vector-search-implementation

181
from majiayu000/claude-skill-registry

Advanced AgentDB Vector Search Implementation operates on 3 fundamental principles:

Architecture Decision Records (ADR)

181
from majiayu000/claude-skill-registry

Documenting significant architectural decisions with context, consequences, and rationale for future reference.

adr-knowledge-base

181
from majiayu000/claude-skill-registry

ADR知見の体系的参照・適用。主要ADR抜粋(ADR_010, 013, 016, 019, 020, 021)・ADR検索・参照方法・技術決定パターン集・ADR作成判断基準。Phase C以降の技術決定時に使用。

adr-graph-easy-architect

181
from majiayu000/claude-skill-registry

ASCII architecture diagrams for ADRs via graph-easy. TRIGGERS - ADR diagram, architecture diagram, ASCII diagram.

adr-architecture

181
from majiayu000/claude-skill-registry

Use when documenting significant technical or architectural decisions that need context, rationale, and consequences recorded. Invoke when choosing between technology options, making infrastructure decisions, establishing standards, migrating systems, or when team needs to understand why a decision was made. Use when user mentions ADR, architecture decision, technical decision record, or decision documentation.

add_platform.research

181
from majiayu000/claude-skill-registry

Captures CLI configuration and hooks system documentation for the new platform. Use when starting platform integration.

add-knowledge

181
from majiayu000/claude-skill-registry

Add notes and learnings to Tim's work knowledge base at Spotify from any Claude Code session

acc-testing-knowledge

181
from majiayu000/claude-skill-registry

Testing knowledge base for PHP 8.5 projects. Provides testing pyramid, AAA pattern, naming conventions, isolation principles, DDD testing guidelines, and PHPUnit patterns.

acc-stability-patterns-knowledge

181
from majiayu000/claude-skill-registry

Stability Patterns knowledge base. Provides patterns, antipatterns, and PHP-specific guidelines for Circuit Breaker, Retry, Rate Limiter, Bulkhead, and resilience audits.

acc-solid-knowledge

181
from majiayu000/claude-skill-registry

SOLID principles knowledge base for PHP 8.5 projects. Provides quick reference for SRP, OCP, LSP, ISP, DIP with detection patterns, PHP examples, and antipattern identification. Use for architecture audits and code quality reviews.