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-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
## 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