acc-architecture-doc-template
npx skills add https://github.com/dykyi-roman/awesome-claude-code --skill acc-architecture-doc-template
Agent 安装分布
Skill 文档
Architecture Documentation Template Generator
Generate comprehensive architecture documentation for PHP projects.
Document Structure
# Architecture
## Overview
{high-level description}
## Directory Structure
{annotated project tree}
## System Context
{C4 context diagram}
## Architecture Layers
{layer descriptions}
## Components
{component descriptions}
## Data Flow
{sequence diagrams}
## Technology Stack
{technology decisions}
## Architecture Decisions
{link to ADRs}
## Deployment
{deployment diagram}
Section Templates
Directory Structure Section
## Directory Structure
project/ âââ src/ # Source code â âââ Domain/ # Domain Layer (DDD) â â âââ Entity/ # Domain entities â â âââ ValueObject/ # Value objects â â âââ Repository/ # Repository interfaces â â âââ Service/ # Domain services â â âââ Event/ # Domain events â âââ Application/ # Application Layer â â âââ UseCase/ # Use cases / Commands / Queries â â âââ DTO/ # Data Transfer Objects â â âââ Service/ # Application services â âââ Infrastructure/ # Infrastructure Layer â â âââ Persistence/ # Repository implementations â â âââ Http/ # HTTP clients â â âââ Messaging/ # Queue adapters â â âââ Cache/ # Cache adapters â âââ Presentation/ # Presentation Layer â âââ Api/ # REST API (Actions, Requests, Responses) â âââ Web/ # Web controllers â âââ Console/ # CLI commands âââ tests/ # Test suite â âââ Unit/ # Unit tests (mirrors src/) â âââ Integration/ # Integration tests â âââ Functional/ # E2E / Functional tests âââ config/ # Configuration files âââ public/ # Web root âââ docker/ # Docker configuration âââ docs/ # Documentation âââ architecture/ # Architecture docs âââ adr/ # Architecture Decision Records âââ api/ # API documentation
### Generation Command
```bash
tree -L 3 -I 'vendor|node_modules|.git|var|cache' --dirsfirst
Annotation Rules
| Rule | Description |
|---|---|
| Layer name | Add DDD layer in comment |
| Purpose | Describe directory purpose |
| Depth | Max 3 levels in main docs |
| Details | Link to subdirectory READMEs |
### Overview Section
```markdown
## Overview
{Project Name} follows {Architecture Style} (e.g., Clean Architecture, DDD, Hexagonal).
### Key Principles
- **Separation of Concerns** â Each layer has distinct responsibility
- **Dependency Rule** â Dependencies point inward (Domain is center)
- **Testability** â Business logic isolated from infrastructure
- **Framework Independence** â Core logic doesn't depend on frameworks
### High-Level Structure
âââââââââââââââââââââââââââââââââââââââââââ â Presentation Layer â â (Actions, Responders) â ââââââââââââââââââââââââââââââââââââââââââ⤠â Application Layer â â (UseCases, Services) â ââââââââââââââââââââââââââââââââââââââââââ⤠â Domain Layer â â (Entities, Value Objects, Events) â ââââââââââââââââââââââââââââââââââââââââââ⤠â Infrastructure Layer â â (Repositories, Adapters, DB) â âââââââââââââââââââââââââââââââââââââââââââ
System Context Section
## System Context
```mermaid
flowchart TB
subgraph boundary["{System Name}"]
S[("{System}\n{Brief Description}")]
end
U1[("ð¤ {Actor 1}")]
U2[("ð¤ {Actor 2}")]
ES1[("ð¦ {External System 1}")]
ES2[("ð¦ {External System 2}")]
U1 -->|"{interaction}"| S
U2 -->|"{interaction}"| S
S -->|"{integration}"| ES1
S -->|"{integration}"| ES2
Actors
| Actor | Description |
|---|---|
| {Actor 1} | {Description} |
| {Actor 2} | {Description} |
External Systems
| System | Purpose | Integration |
|---|---|---|
| {System 1} | {Purpose} | {Protocol/API} |
| {System 2} | {Purpose} | {Protocol/API} |
### Architecture Layers Section
```markdown
## Architecture Layers
### Presentation Layer
**Responsibility:** Handle HTTP requests and responses
**Components:**
- `Api/` â REST API endpoints (Actions + Responders)
- `Web/` â Web interface (Actions + Responders)
- `Console/` â CLI commands
**Rules:**
- No business logic
- Validate input
- Call Application layer
- Format output
### Application Layer
**Responsibility:** Orchestrate business operations
**Components:**
- `UseCase/` â Application-specific business rules
- `Service/` â Cross-cutting application services
- `DTO/` â Data transfer objects
**Rules:**
- Orchestrate Domain objects
- Handle transactions
- No infrastructure concerns
### Domain Layer
**Responsibility:** Core business logic
**Components:**
- `Entity/` â Business objects with identity
- `ValueObject/` â Immutable value concepts
- `Event/` â Domain events
- `Repository/` â Repository interfaces
- `Service/` â Domain services
**Rules:**
- No external dependencies
- Pure business logic
- Self-validating objects
### Infrastructure Layer
**Responsibility:** Technical implementations
**Components:**
- `Persistence/` â Repository implementations
- `Adapter/` â External service adapters
- `Cache/` â Caching implementations
- `Queue/` â Queue implementations
**Rules:**
- Implement Domain interfaces
- Handle technical concerns
- No business logic
Components Section
## Components
```mermaid
flowchart TB
subgraph presentation[Presentation Layer]
AC[Action]
RS[Responder]
end
subgraph application[Application Layer]
UC[UseCase]
AS[AppService]
end
subgraph domain[Domain Layer]
EN[Entity]
VO[ValueObject]
DE[DomainEvent]
RI[Repository<br/>Interface]
end
subgraph infrastructure[Infrastructure Layer]
RP[Repository<br/>Impl]
AD[Adapter]
CA[Cache]
end
AC --> UC
UC --> EN
UC --> RI
RP -.-> RI
RP --> CA
Component Descriptions
| Component | Layer | Responsibility |
|---|---|---|
| Action | Presentation | HTTP request handling |
| Responder | Presentation | HTTP response building |
| UseCase | Application | Business operation orchestration |
| Entity | Domain | Business object with identity |
| ValueObject | Domain | Immutable value concept |
| Repository | Infrastructure | Data persistence |
### Data Flow Section
```markdown
## Data Flow
### {Operation Name} Flow
```mermaid
sequenceDiagram
participant C as Client
participant A as Action
participant U as UseCase
participant E as Entity
participant R as Repository
participant D as Database
C->>A: {Request}
A->>A: Validate & Map to DTO
A->>U: Execute(dto)
U->>R: find(id)
R->>D: SELECT
D-->>R: row
R-->>U: entity
U->>E: {operation}()
E-->>U: result
U->>R: save(entity)
R->>D: UPDATE
D-->>R: ok
U-->>A: Result
A->>A: Build Response
A-->>C: {Response}
### Technology Stack Section
```markdown
## Technology Stack
| Layer | Technology | Purpose |
|-------|------------|---------|
| Language | PHP 8.5 | Type safety, modern features |
| Framework | Symfony 7.x | HTTP, DI, Console |
| ORM | Doctrine 3.x | Database abstraction |
| Database | PostgreSQL 16 | Primary storage |
| Cache | Redis 7.x | Session, cache |
| Queue | RabbitMQ 3.x | Async processing |
| API | OpenAPI 3.1 | API specification |
### Technology Decisions
| Decision | Rationale |
|----------|-----------|
| PostgreSQL over MySQL | JSONB support, better type system |
| Symfony over Laravel | More explicit, better DI |
| Redis over Memcached | Data structures, persistence |
ADR Link Section
## Architecture Decisions
Key decisions are documented as ADRs:
| ADR | Status | Title |
|-----|--------|-------|
| [ADR-001](docs/adr/001-use-ddd.md) | Accepted | Use DDD Architecture |
| [ADR-002](docs/adr/002-cqrs.md) | Accepted | Implement CQRS |
| [ADR-003](docs/adr/003-event-sourcing.md) | Proposed | Consider Event Sourcing |
Complete Example
# Architecture
## Overview
Order Management System follows Domain-Driven Design with Clean Architecture principles.
### Key Principles
- **Domain-Centric** â Business logic in Domain layer
- **Dependency Inversion** â Abstractions over implementations
- **Bounded Contexts** â Order, Inventory, Shipping
## Directory Structure
order-management/ âââ src/ â âââ Order/ # Order Bounded Context â â âââ Domain/ # Domain Layer â â âââ Application/ # Application Layer â â âââ Infrastructure/ # Infrastructure Layer â â âââ Presentation/ # Presentation Layer â âââ Inventory/ # Inventory Bounded Context â âââ Shipping/ # Shipping Bounded Context âââ tests/ âââ config/ âââ docs/
## System Context
```mermaid
flowchart TB
subgraph boundary["Order Management System"]
S[("ð¦ OMS\nManages orders lifecycle")]
end
Customer[("ð¤ Customer")]
Admin[("ð¤ Admin")]
Payment[("ð³ Payment Gateway")]
Shipping[("ð Shipping Provider")]
Customer -->|"Place orders"| S
Admin -->|"Manage orders"| S
S -->|"Process payments"| Payment
S -->|"Ship orders"| Shipping
Architecture Layers
[… layer descriptions …]
Technology Stack
| Layer | Technology | Purpose |
|---|---|---|
| Language | PHP 8.5 | Type safety |
| Framework | Symfony 7.2 | HTTP, DI |
| Database | PostgreSQL 16 | Storage |
| Cache | Redis 7.4 | Performance |
| Queue | RabbitMQ 3.13 | Async |
Architecture Decisions
| ADR | Status | Title |
|---|---|---|
| ADR-001 | Accepted | Use DDD |
| ADR-002 | Accepted | Use CQRS |
## Generation Instructions
When generating ARCHITECTURE.md:
1. **Analyze** project structure for layer organization
2. **Identify** architectural style (DDD, Clean, Hexagonal)
3. **Map** components to layers
4. **Create** context diagram with actors/systems
5. **Generate** component diagram
6. **List** technology stack from `composer.json`
7. **Link** existing ADRs if present