feat(expansion-packs): add C4 Architecture expansion pack with comprehensive documentation and workflows
- Introduced the BMAD C4 Architecture expansion pack, including detailed README and installation instructions. - Added configuration files, agent definitions, and templates for C4 model diagrams. - Implemented workflows for architecture review and C4 model visualization. - Included checklists and guidelines for quality assurance in C4 modeling. This expansion enhances the BMad-Method framework by providing tools for effective architecture visualization and documentation.
This commit is contained in:
Mo
parent
f09e282d72
commit
2e5bfbfcec
|
|
@ -46,3 +46,4 @@ test-project-install/*
|
|||
sample-project/*
|
||||
flattened-codebase.xml
|
||||
*.stats.md
|
||||
codealike.json
|
||||
|
|
|
|||
|
|
@ -1,3 +1,101 @@
|
|||
# BMad Method Expansion Packs
|
||||
|
||||
Expansion packs extend BMad-Method beyond traditional software development, providing specialized agent teams, templates, and workflows for specific domains and industries. Each pack is a self-contained ecosystem designed to bring the power of AI-assisted workflows to any field. Coming soon.
|
||||
Expansion packs extend BMad-Method beyond traditional software development, providing specialized agent teams, templates, and workflows for specific domains and industries. Each pack is a self-contained ecosystem designed to bring the power of AI-assisted workflows to any field.
|
||||
|
||||
## Available Expansion Packs
|
||||
|
||||
### 🏛️ C4 Architecture
|
||||
|
||||
**Purpose**: C4 model visualization and Structurizr DSL generation
|
||||
**Agents**: C4 Architect (Simon)
|
||||
**Focus**: Architecture diagrams, system visualization, stakeholder communication
|
||||
**Status**: ✅ Available
|
||||
|
||||
### 🎮 Game Development
|
||||
|
||||
**Godot Game Dev**: 2D/3D game development with Godot engine
|
||||
**2D Phaser Game Dev**: Web-based 2D games with Phaser.js
|
||||
**2D Unity Game Dev**: 2D games with Unity engine
|
||||
**Status**: ✅ Available
|
||||
|
||||
### ✍️ Creative Writing
|
||||
|
||||
**Purpose**: Creative writing and content creation
|
||||
**Agents**: Writer, Editor, Content Strategist
|
||||
**Focus**: Story development, content planning, creative workflows
|
||||
**Status**: ✅ Available
|
||||
|
||||
### 🔧 Infrastructure & DevOps
|
||||
|
||||
**Purpose**: Infrastructure and DevOps workflows
|
||||
**Agents**: DevOps Engineer (Alex)
|
||||
**Focus**: Cloud infrastructure, CI/CD, platform engineering
|
||||
**Status**: ✅ Available
|
||||
|
||||
## Installation
|
||||
|
||||
### Install Specific Expansion Pack
|
||||
|
||||
```bash
|
||||
# C4 Architecture
|
||||
cd expansion-packs/bmad-c4-architecture
|
||||
./install.sh
|
||||
|
||||
# Game Development
|
||||
npm run install:expansion godot-game-dev
|
||||
|
||||
# Infrastructure & DevOps
|
||||
npm run install:expansion infrastructure-devops
|
||||
```
|
||||
|
||||
### Interactive Installation
|
||||
|
||||
```bash
|
||||
npx bmad-method install
|
||||
```
|
||||
|
||||
## Creating Custom Expansion Packs
|
||||
|
||||
Expansion packs follow a standard structure:
|
||||
|
||||
```
|
||||
expansion-pack-name/
|
||||
├── agents/ # Specialized agent definitions
|
||||
├── agent-teams/ # Team configurations
|
||||
├── tasks/ # Workflow instructions
|
||||
├── templates/ # Document templates
|
||||
├── checklists/ # Quality assurance
|
||||
├── data/ # Knowledge base
|
||||
├── workflows/ # Process definitions
|
||||
├── utils/ # Utilities and tools
|
||||
├── config.yaml # Pack configuration
|
||||
├── README.md # Documentation
|
||||
└── install.sh # Installation script
|
||||
```
|
||||
|
||||
### Key Components
|
||||
|
||||
- **Agents**: Specialized personas for the domain
|
||||
- **Templates**: Domain-specific document templates
|
||||
- **Tasks**: Workflow instructions and processes
|
||||
- **Checklists**: Quality assurance and validation
|
||||
- **Data**: Knowledge base and guidelines
|
||||
- **Workflows**: Complete process flows
|
||||
- **Config**: Domain-specific configuration
|
||||
|
||||
## Contributing
|
||||
|
||||
We welcome contributions to existing expansion packs and new expansion pack ideas! Please see our [Contributing Guide](../CONTRIBUTING.md) for details.
|
||||
|
||||
### Ideas for New Expansion Packs
|
||||
|
||||
- Mobile App Development (React Native, Flutter)
|
||||
- Data Science & Analytics
|
||||
- Machine Learning & AI
|
||||
- Blockchain & Web3
|
||||
- IoT & Embedded Systems
|
||||
- Content Management Systems
|
||||
- E-commerce Platforms
|
||||
- Healthcare Applications
|
||||
- Financial Services
|
||||
- Education Technology
|
||||
|
|
|
|||
|
|
@ -0,0 +1,475 @@
|
|||
# BMAD C4 Architecture Expansion Pack
|
||||
|
||||
## Overview
|
||||
|
||||
The BMAD C4 Architecture Expansion Pack extends BMad-Method with comprehensive C4 model visualization capabilities using Structurizr DSL. This expansion pack provides specialized agents, templates, and workflows for creating, maintaining, and validating architecture diagrams that effectively communicate system design across all stakeholder levels.
|
||||
|
||||
## What is C4 Model?
|
||||
|
||||
The C4 model is a hierarchical approach to visualizing software architecture through four levels of abstraction:
|
||||
|
||||
- **Context (Level 1)**: Shows how the system fits into the world around it
|
||||
- **Container (Level 2)**: Zooms into the system boundary, showing high-level technical building blocks
|
||||
- **Component (Level 3)**: Zooms into a container to show the components within it
|
||||
- **Code (Level 4)**: Zooms into a component to show how it is implemented
|
||||
|
||||
## Features
|
||||
|
||||
### 🏛️ C4 Architect Agent (Simon)
|
||||
|
||||
- **Specialized Expertise**: C4 model methodology and Structurizr DSL
|
||||
- **Visual Communication**: Creates clear, comprehensive architecture diagrams
|
||||
- **Stakeholder Focus**: Tailors diagrams to audience needs
|
||||
- **Quality Assurance**: Ensures consistency and completeness
|
||||
|
||||
### 📊 Complete C4 Model Support
|
||||
|
||||
- **Context Diagrams**: System in the world view
|
||||
- **Container Diagrams**: High-level technical building blocks
|
||||
- **Component Diagrams**: Internal component structure
|
||||
- **Code Diagrams**: Implementation details (via UML tools)
|
||||
|
||||
### 🔧 Structurizr DSL Integration
|
||||
|
||||
- **Full DSL Support**: Complete Structurizr DSL syntax
|
||||
- **Workspace Management**: Create and manage Structurizr workspaces
|
||||
- **Export Capabilities**: Multiple output formats (PNG, SVG, PDF, DSL)
|
||||
- **Validation**: Syntax and consistency checking
|
||||
|
||||
### 📋 Quality Assurance
|
||||
|
||||
- **Comprehensive Checklists**: Quality validation for all C4 levels
|
||||
- **Best Practices**: Built-in guidelines and anti-patterns
|
||||
- **Review Workflows**: Architecture review and improvement processes
|
||||
- **Validation Tools**: Model consistency and completeness checks
|
||||
|
||||
## Installation
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- BMAD-METHOD v4 or later
|
||||
- Docker (recommended) OR Java 17+ (for Structurizr Lite Spring Boot)
|
||||
- Node.js and npm
|
||||
|
||||
### Install the Expansion Pack
|
||||
|
||||
```bash
|
||||
# Interactive installation (recommended)
|
||||
npx bmad-method install
|
||||
|
||||
# Or install specific expansion pack
|
||||
npm run install:expansion c4-architecture
|
||||
```
|
||||
|
||||
### Manual Installation
|
||||
|
||||
```bash
|
||||
# Copy expansion pack to your project
|
||||
cp -r expansion-packs/bmad-c4-architecture .bmad-c4-architecture
|
||||
|
||||
# Update your core configuration
|
||||
cp .bmad-c4-architecture/config.yaml .bmad-core/core-config.yaml
|
||||
```
|
||||
|
||||
## Quick Start
|
||||
|
||||
### 1. Activate the C4 Architect Agent
|
||||
|
||||
```bash
|
||||
# In your IDE
|
||||
@c4-architect
|
||||
|
||||
# Or use the agent directly
|
||||
*help
|
||||
```
|
||||
|
||||
### 2. Create Your First C4 Diagram
|
||||
|
||||
```bash
|
||||
# Create a context diagram
|
||||
*create-context
|
||||
|
||||
# Create a container diagram
|
||||
*create-container
|
||||
|
||||
# Create a component diagram
|
||||
*create-component
|
||||
```
|
||||
|
||||
### 3. Generate Complete Workspace
|
||||
|
||||
```bash
|
||||
# Generate full Structurizr DSL workspace
|
||||
*generate-dsl
|
||||
|
||||
# Validate your model
|
||||
*validate-model
|
||||
|
||||
# Export diagrams
|
||||
*export-diagrams
|
||||
```
|
||||
|
||||
## Agent Commands
|
||||
|
||||
### Core Commands
|
||||
|
||||
- `*help` - Show all available commands
|
||||
- `*create-context` - Create C4 Context diagram (Level 1)
|
||||
- `*create-container` - Create C4 Container diagram (Level 2)
|
||||
- `*create-component` - Create C4 Component diagram (Level 3)
|
||||
- `*generate-dsl` - Generate complete Structurizr DSL workspace
|
||||
- `*validate-model` - Validate C4 model consistency and completeness
|
||||
- `*create-workspace` - Create new Structurizr workspace from scratch
|
||||
- `*update-diagram` - Update existing diagram with new elements
|
||||
- `*export-diagrams` - Export diagrams in various formats
|
||||
- `*review-architecture` - Review and suggest improvements to architecture
|
||||
- `*exit` - Exit the C4 Architect agent
|
||||
|
||||
## Team Configurations
|
||||
|
||||
### Architecture Team
|
||||
|
||||
```yaml
|
||||
agents: ['architect', 'c4-architect']
|
||||
```
|
||||
|
||||
Complete architecture team with C4 visualization capabilities.
|
||||
|
||||
### Visualization Team
|
||||
|
||||
```yaml
|
||||
agents: ['c4-architect']
|
||||
```
|
||||
|
||||
Focused team for architecture visualization and documentation.
|
||||
|
||||
### Full Development Team
|
||||
|
||||
```yaml
|
||||
agents: ['analyst', 'pm', 'architect', 'c4-architect', 'dev', 'qa']
|
||||
```
|
||||
|
||||
Complete development team including C4 model visualization.
|
||||
|
||||
## Workflows
|
||||
|
||||
### C4 Visualization Workflow
|
||||
|
||||
Complete workflow for creating C4 model diagrams:
|
||||
|
||||
1. **Planning**: Create workspace and gather information
|
||||
2. **Creation**: Build context, container, and component diagrams
|
||||
3. **Validation**: Validate diagrams and ensure quality
|
||||
4. **Export**: Export diagrams and create documentation
|
||||
|
||||
### Architecture Review Workflow
|
||||
|
||||
Workflow for reviewing and improving existing architecture:
|
||||
|
||||
1. **Analysis**: Review existing architecture and identify issues
|
||||
2. **Improvement**: Update diagrams based on findings
|
||||
3. **Documentation**: Document changes and export updated diagrams
|
||||
|
||||
## Templates
|
||||
|
||||
### C4 Context Template
|
||||
|
||||
Interactive template for creating context diagrams with:
|
||||
|
||||
- System overview and business context
|
||||
- User identification and goals
|
||||
- External system mapping
|
||||
- Relationship definition
|
||||
|
||||
### C4 Container Template
|
||||
|
||||
Template for container diagrams including:
|
||||
|
||||
- Container identification and technologies
|
||||
- Communication patterns
|
||||
- Security boundaries
|
||||
- Data flow mapping
|
||||
|
||||
### C4 Component Template
|
||||
|
||||
Template for component diagrams with:
|
||||
|
||||
- Component identification and responsibilities
|
||||
- Interface definitions
|
||||
- Data flow patterns
|
||||
- Technology specifications
|
||||
|
||||
### Structurizr Workspace Template
|
||||
|
||||
Complete workspace template for all C4 model levels with:
|
||||
|
||||
- Workspace configuration
|
||||
- Multi-level diagram support
|
||||
- Styling and theming options
|
||||
- Export configuration
|
||||
|
||||
## Data and Guidelines
|
||||
|
||||
### C4 Model Guidelines
|
||||
|
||||
Comprehensive guidelines covering:
|
||||
|
||||
- C4 model principles and best practices
|
||||
- Naming conventions and consistency
|
||||
- Common anti-patterns to avoid
|
||||
- Quality standards and validation
|
||||
|
||||
### Technical Preferences
|
||||
|
||||
Integration with BMAD-METHOD technical preferences system for:
|
||||
|
||||
- Consistent technology choices
|
||||
- Styling preferences
|
||||
- Export format preferences
|
||||
- Validation criteria
|
||||
|
||||
## Checklists
|
||||
|
||||
### C4 Model Quality Checklist
|
||||
|
||||
Comprehensive quality assurance checklist covering:
|
||||
|
||||
- **Context Diagram**: Completeness, relationships, clarity
|
||||
- **Container Diagram**: Technology choices, architecture, scalability
|
||||
- **Component Diagram**: Design principles, interfaces, dependencies
|
||||
- **DSL Quality**: Syntax, structure, best practices
|
||||
- **Visual Quality**: Layout, styling, clarity
|
||||
- **Documentation**: Completeness, consistency, accuracy
|
||||
|
||||
## Integration with Core BMad
|
||||
|
||||
### Planning Phase
|
||||
|
||||
- Create context diagrams to understand system scope
|
||||
- Use diagrams for stakeholder communication
|
||||
- Validate requirements against architecture
|
||||
|
||||
### Architecture Phase
|
||||
|
||||
- Create container diagrams for technical design
|
||||
- Use component diagrams for detailed design
|
||||
- Validate design decisions
|
||||
|
||||
### Development Phase
|
||||
|
||||
- Keep diagrams updated with implementation
|
||||
- Use diagrams for developer onboarding
|
||||
- Document architectural decisions
|
||||
|
||||
### Review Phase
|
||||
|
||||
- Regular diagram updates
|
||||
- Version control diagram changes
|
||||
- Use diagrams for impact analysis
|
||||
|
||||
## External Dependencies
|
||||
|
||||
### Required Tools
|
||||
|
||||
- **Structurizr Lite**: For diagram visualization and editing
|
||||
- **Docker** (recommended) OR **Java 17+**: Required runtime for Structurizr Lite
|
||||
|
||||
### Optional Services
|
||||
|
||||
- **Structurizr Cloud**: For cloud-based diagram management
|
||||
- **Version Control**: For diagram versioning and collaboration
|
||||
|
||||
## Configuration
|
||||
|
||||
### Structurizr Lite Setup
|
||||
|
||||
#### Option 1: Docker (Recommended)
|
||||
|
||||
```bash
|
||||
# Pull the Docker image
|
||||
docker pull structurizr/lite
|
||||
|
||||
# Create a data directory
|
||||
mkdir -p ~/structurizr
|
||||
|
||||
# Run Structurizr Lite
|
||||
docker run -it --rm -p 8080:8080 -v ~/structurizr:/usr/local/structurizr structurizr/lite
|
||||
|
||||
# Access at http://localhost:8080
|
||||
```
|
||||
|
||||
#### Option 2: Spring Boot
|
||||
|
||||
```bash
|
||||
# Download the WAR file
|
||||
wget https://github.com/structurizr/lite/releases/latest/download/structurizr-lite.war
|
||||
|
||||
# Create a data directory
|
||||
mkdir -p ~/structurizr
|
||||
|
||||
# Run Structurizr Lite (requires Java 17+)
|
||||
java -jar structurizr-lite.war ~/structurizr
|
||||
|
||||
# Access at http://localhost:8080
|
||||
```
|
||||
|
||||
### Expansion Pack Configuration
|
||||
|
||||
```yaml
|
||||
# .bmad-c4-architecture/config.yaml
|
||||
structurizr_lite_url: 'http://localhost:8080'
|
||||
default_theme: 'default'
|
||||
export_formats: ['png', 'svg', 'pdf', 'dsl']
|
||||
auto_layout: true
|
||||
validation_strict: true
|
||||
```
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Example 1: Create Context Diagram
|
||||
|
||||
```bash
|
||||
@c4-architect
|
||||
*create-context
|
||||
|
||||
# Follow the interactive prompts:
|
||||
# 1. System name: "E-commerce Platform"
|
||||
# 2. Primary users: "Customers, Administrators, Support Staff"
|
||||
# 3. External systems: "Payment Gateway, Email Service, Inventory System"
|
||||
# 4. User interactions: "Customers browse products, place orders"
|
||||
```
|
||||
|
||||
### Example 2: Generate Complete Workspace
|
||||
|
||||
```bash
|
||||
@c4-architect
|
||||
*generate-dsl
|
||||
|
||||
# Creates complete Structurizr DSL workspace with:
|
||||
# - All C4 model levels
|
||||
# - Proper relationships
|
||||
# - Consistent styling
|
||||
# - Export-ready format
|
||||
```
|
||||
|
||||
### Example 3: Review and Update Architecture
|
||||
|
||||
```bash
|
||||
@c4-architect
|
||||
*review-architecture
|
||||
|
||||
# Reviews existing diagrams and provides:
|
||||
# - Issue identification
|
||||
# - Improvement suggestions
|
||||
# - Quality assessment
|
||||
# - Update recommendations
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### 1. Start Simple
|
||||
|
||||
- Begin with context diagrams
|
||||
- Add detail gradually
|
||||
- Focus on key relationships first
|
||||
|
||||
### 2. Maintain Consistency
|
||||
|
||||
- Use consistent naming conventions
|
||||
- Apply consistent styling
|
||||
- Follow established patterns
|
||||
|
||||
### 3. Regular Updates
|
||||
|
||||
- Keep diagrams current with system changes
|
||||
- Review and update regularly
|
||||
- Version control diagram changes
|
||||
|
||||
### 4. Stakeholder Communication
|
||||
|
||||
- Tailor diagrams to audience
|
||||
- Use appropriate abstraction levels
|
||||
- Include relevant context
|
||||
|
||||
### 5. Tool Integration
|
||||
|
||||
- Use Structurizr Lite for visualization
|
||||
- Integrate with documentation systems
|
||||
- Export to various formats as needed
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common Issues
|
||||
|
||||
#### Structurizr Lite Not Running
|
||||
|
||||
```bash
|
||||
# Check if Structurizr Lite is running
|
||||
curl http://localhost:8080
|
||||
|
||||
# Start Structurizr Lite (Docker)
|
||||
docker run -it --rm -p 8080:8080 -v ~/structurizr:/usr/local/structurizr structurizr/lite
|
||||
|
||||
# Or start Structurizr Lite (Spring Boot)
|
||||
java -jar structurizr-lite.war ~/structurizr
|
||||
```
|
||||
|
||||
#### DSL Syntax Errors
|
||||
|
||||
```bash
|
||||
# Validate DSL syntax
|
||||
*validate-model
|
||||
|
||||
# Check for common issues:
|
||||
# - Missing element definitions
|
||||
# - Invalid relationships
|
||||
# - Incorrect view configurations
|
||||
```
|
||||
|
||||
#### Export Issues
|
||||
|
||||
```bash
|
||||
# Check export configuration
|
||||
*export-diagrams
|
||||
|
||||
# Verify output directory permissions
|
||||
# Check available disk space
|
||||
# Ensure Structurizr Lite is accessible
|
||||
```
|
||||
|
||||
## Support and Community
|
||||
|
||||
- **Discord Community**: [Join Discord](https://discord.gg/gk8jAdXWmj)
|
||||
- **GitHub Issues**: [Report bugs](https://github.com/bmadcode/bmad-method/issues)
|
||||
- **Documentation**: [Browse docs](https://github.com/bmadcode/bmad-method/docs)
|
||||
- **YouTube**: [BMadCode Channel](https://www.youtube.com/@BMadCode)
|
||||
|
||||
## Contributing
|
||||
|
||||
We welcome contributions to the C4 Architecture Expansion Pack! Please see our [Contributing Guide](CONTRIBUTING.md) for details.
|
||||
|
||||
### Areas for Contribution
|
||||
|
||||
- Additional C4 model templates
|
||||
- New export formats
|
||||
- Enhanced validation rules
|
||||
- Integration with other tools
|
||||
- Documentation improvements
|
||||
|
||||
## License
|
||||
|
||||
This expansion pack is part of the BMAD-METHOD project and follows the same license terms.
|
||||
|
||||
## Version History
|
||||
|
||||
### v1.0.0
|
||||
|
||||
- Initial release
|
||||
- Complete C4 model support
|
||||
- Structurizr DSL integration
|
||||
- Quality assurance tools
|
||||
- Export capabilities
|
||||
|
||||
---
|
||||
|
||||
**Remember**: The C4 Architecture Expansion Pack is designed to enhance your architecture visualization capabilities, not replace your architectural expertise. Use it as a powerful tool to create clear, professional architecture diagrams that effectively communicate your system design.
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
name: "Architecture Team"
|
||||
description: "Complete architecture team with C4 model visualization capabilities"
|
||||
version: "1.0.0"
|
||||
|
||||
agents:
|
||||
- "architect" # Core system architect
|
||||
- "c4-architect" # C4 model specialist
|
||||
|
||||
workflows:
|
||||
- "architecture-design"
|
||||
- "c4-visualization"
|
||||
- "architecture-review"
|
||||
|
||||
capabilities:
|
||||
- "System architecture design"
|
||||
- "C4 model diagram creation"
|
||||
- "Architecture documentation"
|
||||
- "Visual communication"
|
||||
- "Stakeholder presentations"
|
||||
|
||||
use_cases:
|
||||
- "Complete system architecture design with visual diagrams"
|
||||
- "Architecture review and validation"
|
||||
- "Stakeholder communication and presentations"
|
||||
- "Documentation and knowledge transfer"
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
name: "Full Development Team with C4"
|
||||
description: "Complete development team including C4 model visualization capabilities"
|
||||
version: "1.0.0"
|
||||
|
||||
agents:
|
||||
- "analyst" # Business analysis
|
||||
- "pm" # Product management
|
||||
- "architect" # System architecture
|
||||
- "c4-architect" # C4 model visualization
|
||||
- "dev" # Development
|
||||
- "qa" # Quality assurance
|
||||
|
||||
workflows:
|
||||
- "greenfield-fullstack"
|
||||
- "brownfield-fullstack"
|
||||
- "c4-visualization"
|
||||
- "architecture-review"
|
||||
|
||||
capabilities:
|
||||
- "Complete development lifecycle"
|
||||
- "C4 model diagram creation"
|
||||
- "Architecture visualization"
|
||||
- "Stakeholder communication"
|
||||
- "Quality assurance"
|
||||
- "Documentation generation"
|
||||
|
||||
use_cases:
|
||||
- "End-to-end project development with visual architecture"
|
||||
- "Complex system design and implementation"
|
||||
- "Architecture documentation and communication"
|
||||
- "Stakeholder presentations and reviews"
|
||||
- "Knowledge transfer and onboarding"
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
name: "Visualization Team"
|
||||
description: "Focused team for architecture visualization and documentation"
|
||||
version: "1.0.0"
|
||||
|
||||
agents:
|
||||
- "c4-architect" # C4 model specialist
|
||||
|
||||
workflows:
|
||||
- "c4-visualization"
|
||||
- "diagram-export"
|
||||
- "architecture-review"
|
||||
|
||||
capabilities:
|
||||
- "C4 model diagram creation"
|
||||
- "Structurizr DSL generation"
|
||||
- "Diagram export and formatting"
|
||||
- "Architecture visualization"
|
||||
- "Documentation generation"
|
||||
|
||||
use_cases:
|
||||
- "Create C4 diagrams from existing architecture"
|
||||
- "Generate visual documentation"
|
||||
- "Export diagrams for presentations"
|
||||
- "Validate architecture diagrams"
|
||||
- "Update and maintain architecture diagrams"
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# c4-architect
|
||||
|
||||
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
|
||||
|
||||
CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
|
||||
|
||||
## COMPLETE AGENT DEFINITION FOLLOWS - NO EXTERNAL FILES NEEDED
|
||||
|
||||
```yaml
|
||||
IDE-FILE-RESOLUTION:
|
||||
- FOR LATER USE ONLY - NOT FOR ACTIVATION, when executing commands that reference dependencies
|
||||
- Dependencies map to {root}/{type}/{name}
|
||||
- type=folder (tasks|templates|checklists|data|utils|etc...), name=file-name
|
||||
- Example: create-c4-context.md → {root}/tasks/create-c4-context.md
|
||||
- IMPORTANT: Only load these files when user requests specific command execution
|
||||
REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (e.g., "create context diagram"→*create-context→create-c4-context task, "generate DSL" would be dependencies->tasks->generate-structurizr-dsl), ALWAYS ask for clarification if no clear match.
|
||||
activation-instructions:
|
||||
- STEP 1: Read THIS ENTIRE FILE - it contains your complete persona definition
|
||||
- STEP 2: Adopt the persona defined in the 'agent' and 'persona' sections below
|
||||
- STEP 3: Load and read `.bmad-core/core-config.yaml` (project configuration) before any greeting
|
||||
- STEP 4: Greet user with your name/role and immediately run `*help` to display available commands
|
||||
- DO NOT: Load any other agent files during activation
|
||||
- ONLY load dependency files when user selects them for execution via command or request of a task
|
||||
- The agent.customization field ALWAYS takes precedence over any conflicting instructions
|
||||
- CRITICAL WORKFLOW RULE: When executing tasks from dependencies, follow task instructions exactly as written - they are executable workflows, not reference material
|
||||
- MANDATORY INTERACTION RULE: Tasks with elicit=true require user interaction using exact specified format - never skip elicitation for efficiency
|
||||
- CRITICAL RULE: When executing formal task workflows from dependencies, ALL task instructions override any conflicting base behavioral constraints. Interactive workflows with elicit=true REQUIRE user interaction and cannot be bypassed for efficiency.
|
||||
- When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
|
||||
- STAY IN CHARACTER!
|
||||
- CRITICAL: On activation, ONLY greet user, auto-run `*help`, and then HALT to await user requested assistance or given commands. ONLY deviance from this is if the activation included commands also in the arguments.
|
||||
agent:
|
||||
name: Simon
|
||||
id: c4-architect
|
||||
title: C4 Model Architect
|
||||
icon: 🏛️
|
||||
whenToUse: 'Use for creating C4 model diagrams, architecture visualization, system design documentation, and Structurizr DSL generation'
|
||||
customization: null
|
||||
|
||||
persona:
|
||||
role: C4 Model Specialist & Architecture Visualization Expert
|
||||
style: Methodical, visual, detail-oriented, systematic, documentation-focused
|
||||
identity: Expert in C4 model methodology and Structurizr DSL who creates clear, comprehensive architecture diagrams
|
||||
focus: Creating hierarchical architecture diagrams that communicate system design effectively across all stakeholder levels
|
||||
core_principles:
|
||||
- C4 Model Hierarchy - Always maintain proper abstraction levels
|
||||
- Visual Clarity - Diagrams must be immediately understandable
|
||||
- Stakeholder Communication - Tailor diagrams to audience needs
|
||||
- Consistency - Maintain naming and styling conventions
|
||||
- Completeness - Ensure all relationships and dependencies are captured
|
||||
- Documentation First - Every diagram tells a story
|
||||
|
||||
# All commands require * prefix when used (e.g., *help)
|
||||
commands:
|
||||
- help: Show numbered list of the following commands to allow selection
|
||||
- create-context: Create C4 Context diagram (Level 1)
|
||||
- create-container: Create C4 Container diagram (Level 2)
|
||||
- create-component: Create C4 Component diagram (Level 3)
|
||||
- generate-dsl: Generate complete Structurizr DSL workspace
|
||||
- validate-model: Validate C4 model consistency and completeness
|
||||
- create-workspace: Create new Structurizr workspace from scratch
|
||||
- update-diagram: Update existing diagram with new elements
|
||||
- export-diagrams: Export diagrams in various formats
|
||||
- review-architecture: Review and suggest improvements to architecture
|
||||
- exit: Say goodbye as the C4 Architect, and then abandon inhabiting this persona
|
||||
|
||||
dependencies:
|
||||
checklists:
|
||||
- c4-model-checklist.md
|
||||
data:
|
||||
- c4-model-guidelines.md
|
||||
- technical-preferences.md
|
||||
tasks:
|
||||
- create-c4-context.md
|
||||
- create-c4-container.md
|
||||
- create-c4-component.md
|
||||
- generate-structurizr-dsl.md
|
||||
- validate-c4-model.md
|
||||
- create-structurizr-workspace.md
|
||||
- update-c4-diagram.md
|
||||
- export-c4-diagrams.md
|
||||
- review-c4-architecture.md
|
||||
templates:
|
||||
- c4-context-tmpl.yaml
|
||||
- c4-container-tmpl.yaml
|
||||
- c4-component-tmpl.yaml
|
||||
- structurizr-workspace-tmpl.yaml
|
||||
```
|
||||
|
|
@ -0,0 +1,241 @@
|
|||
# C4 Model Quality Assurance Checklist
|
||||
|
||||
## Context Diagram (Level 1) Checklist
|
||||
|
||||
### Completeness
|
||||
|
||||
- [ ] All key users are represented
|
||||
- [ ] Main software system is clearly defined
|
||||
- [ ] All external systems are identified
|
||||
- [ ] System description is clear and concise
|
||||
- [ ] Business context is provided
|
||||
|
||||
### Relationships
|
||||
|
||||
- [ ] All user interactions are defined
|
||||
- [ ] System-to-external system relationships are clear
|
||||
- [ ] Relationship labels are descriptive
|
||||
- [ ] Technology protocols are specified
|
||||
- [ ] Data flow direction is clear
|
||||
|
||||
### Clarity
|
||||
|
||||
- [ ] Diagram is understandable to non-technical stakeholders
|
||||
- [ ] Element names are business-focused
|
||||
- [ ] No technical jargon in descriptions
|
||||
- [ ] Layout is clean and uncluttered
|
||||
- [ ] Relationships don't cross unnecessarily
|
||||
|
||||
### Best Practices
|
||||
|
||||
- [ ] Follows C4 model principles
|
||||
- [ ] Appropriate abstraction level
|
||||
- [ ] Consistent naming conventions
|
||||
- [ ] No missing elements
|
||||
- [ ] Technology choices are justified
|
||||
|
||||
## Container Diagram (Level 2) Checklist
|
||||
|
||||
### Completeness
|
||||
|
||||
- [ ] All major containers are represented
|
||||
- [ ] Technology stack is specified for each container
|
||||
- [ ] Container responsibilities are clear
|
||||
- [ ] All external systems are included
|
||||
- [ ] User interactions are shown
|
||||
|
||||
### Relationships
|
||||
|
||||
- [ ] Container-to-container communication is defined
|
||||
- [ ] Data flow patterns are clear
|
||||
- [ ] Security boundaries are identified
|
||||
- [ ] Communication protocols are specified
|
||||
- [ ] No circular dependencies
|
||||
|
||||
### Technology
|
||||
|
||||
- [ ] Technology choices are appropriate
|
||||
- [ ] Scalability considerations are addressed
|
||||
- [ ] Security requirements are met
|
||||
- [ ] Performance implications are considered
|
||||
- [ ] Maintenance requirements are reasonable
|
||||
|
||||
### Architecture
|
||||
|
||||
- [ ] Architecture patterns are appropriate
|
||||
- [ ] Separation of concerns is maintained
|
||||
- [ ] Dependencies are minimized
|
||||
- [ ] Interfaces are well-defined
|
||||
- [ ] Error handling is considered
|
||||
|
||||
## Component Diagram (Level 3) Checklist
|
||||
|
||||
### Completeness
|
||||
|
||||
- [ ] All major components are represented
|
||||
- [ ] Component responsibilities are clear
|
||||
- [ ] Interfaces are defined
|
||||
- [ ] Data models are identified
|
||||
- [ ] External dependencies are shown
|
||||
|
||||
### Relationships
|
||||
|
||||
- [ ] Component interactions are logical
|
||||
- [ ] Data flow is clear
|
||||
- [ ] Interface contracts are defined
|
||||
- [ ] Error handling is considered
|
||||
- [ ] Dependencies are minimal
|
||||
|
||||
### Design
|
||||
|
||||
- [ ] Single responsibility principle is followed
|
||||
- [ ] Components are loosely coupled
|
||||
- [ ] Interfaces are well-defined
|
||||
- [ ] Error handling is comprehensive
|
||||
- [ ] Testing considerations are addressed
|
||||
|
||||
### Technology
|
||||
|
||||
- [ ] Technology choices are consistent
|
||||
- [ ] Performance requirements are met
|
||||
- [ ] Security requirements are addressed
|
||||
- [ ] Scalability is considered
|
||||
- [ ] Maintenance is feasible
|
||||
|
||||
## DSL Quality Checklist
|
||||
|
||||
### Syntax
|
||||
|
||||
- [ ] DSL syntax is correct
|
||||
- [ ] All elements are properly defined
|
||||
- [ ] All relationships are valid
|
||||
- [ ] All views are properly configured
|
||||
- [ ] No syntax errors
|
||||
|
||||
### Structure
|
||||
|
||||
- [ ] Workspace structure is logical
|
||||
- [ ] Model organization is clear
|
||||
- [ ] View hierarchy is appropriate
|
||||
- [ ] Styling is consistent
|
||||
- [ ] Documentation is complete
|
||||
|
||||
### Completeness
|
||||
|
||||
- [ ] All referenced elements exist
|
||||
- [ ] All relationships are bidirectional where appropriate
|
||||
- [ ] No orphaned elements
|
||||
- [ ] All views include necessary elements
|
||||
- [ ] Styling is applied consistently
|
||||
|
||||
### Best Practices
|
||||
|
||||
- [ ] Naming conventions are followed
|
||||
- [ ] Descriptions are clear and concise
|
||||
- [ ] Technology labels are appropriate
|
||||
- [ ] Layout preferences are applied
|
||||
- [ ] Theme is consistent
|
||||
|
||||
## Visual Quality Checklist
|
||||
|
||||
### Layout
|
||||
|
||||
- [ ] Elements are properly spaced
|
||||
- [ ] Relationships don't cross unnecessarily
|
||||
- [ ] Grouping is logical
|
||||
- [ ] Layout is clean and readable
|
||||
- [ ] Autolayout is applied
|
||||
|
||||
### Styling
|
||||
|
||||
- [ ] Colors are consistent
|
||||
- [ ] Element shapes are appropriate
|
||||
- [ ] Text is readable
|
||||
- [ ] Icons are meaningful
|
||||
- [ ] Theme is applied consistently
|
||||
|
||||
### Clarity
|
||||
|
||||
- [ ] Diagram is immediately understandable
|
||||
- [ ] Element names are clear
|
||||
- [ ] Relationships are obvious
|
||||
- [ ] Context is appropriate
|
||||
- [ ] Audience needs are met
|
||||
|
||||
## Documentation Checklist
|
||||
|
||||
### Completeness
|
||||
|
||||
- [ ] All elements have descriptions
|
||||
- [ ] All relationships are labeled
|
||||
- [ ] Technology choices are documented
|
||||
- [ ] Design decisions are explained
|
||||
- [ ] Assumptions are stated
|
||||
|
||||
### Quality
|
||||
|
||||
- [ ] Descriptions are clear and concise
|
||||
- [ ] Technical accuracy is maintained
|
||||
- [ ] Business context is provided
|
||||
- [ ] Stakeholder needs are addressed
|
||||
- [ ] Maintenance information is included
|
||||
|
||||
### Consistency
|
||||
|
||||
- [ ] Naming conventions are followed
|
||||
- [ ] Terminology is consistent
|
||||
- [ ] Formatting is uniform
|
||||
- [ ] Style is professional
|
||||
- [ ] Updates are tracked
|
||||
|
||||
## Integration Checklist
|
||||
|
||||
### Workflow Integration
|
||||
|
||||
- [ ] Diagrams support development workflow
|
||||
- [ ] Stakeholder communication is effective
|
||||
- [ ] Documentation is up-to-date
|
||||
- [ ] Version control is maintained
|
||||
- [ ] Change management is in place
|
||||
|
||||
### Tool Integration
|
||||
|
||||
- [ ] Structurizr Lite compatibility
|
||||
- [ ] Export formats are available
|
||||
- [ ] Documentation systems are integrated
|
||||
- [ ] Version control is supported
|
||||
- [ ] Collaboration tools are compatible
|
||||
|
||||
### Maintenance
|
||||
|
||||
- [ ] Update process is defined
|
||||
- [ ] Review cycle is established
|
||||
- [ ] Quality gates are in place
|
||||
- [ ] Training is provided
|
||||
- [ ] Support is available
|
||||
|
||||
## Final Review Checklist
|
||||
|
||||
### Overall Quality
|
||||
|
||||
- [ ] All checklist items are completed
|
||||
- [ ] Stakeholder feedback is incorporated
|
||||
- [ ] Quality standards are met
|
||||
- [ ] Best practices are followed
|
||||
- [ ] Documentation is complete
|
||||
|
||||
### Readiness
|
||||
|
||||
- [ ] Diagrams are ready for use
|
||||
- [ ] Documentation is complete
|
||||
- [ ] Training materials are available
|
||||
- [ ] Support processes are in place
|
||||
- [ ] Maintenance procedures are defined
|
||||
|
||||
### Sign-off
|
||||
|
||||
- [ ] Technical review completed
|
||||
- [ ] Stakeholder approval obtained
|
||||
- [ ] Quality assurance passed
|
||||
- [ ] Documentation approved
|
||||
- [ ] Implementation ready
|
||||
|
|
@ -0,0 +1,103 @@
|
|||
name: "BMAD C4 Architecture"
|
||||
description: "C4 Model and Structurizr DSL specialist expansion pack for architecture visualization"
|
||||
version: "1.0.0"
|
||||
author: "BMAD-METHOD"
|
||||
compatibility: "BMAD-METHOD v4+"
|
||||
|
||||
# Expansion pack metadata
|
||||
metadata:
|
||||
category: "Architecture & Visualization"
|
||||
tags: ["c4-model", "structurizr", "architecture", "diagrams", "visualization"]
|
||||
target_audience: ["architects", "developers", "technical-leads", "stakeholders"]
|
||||
complexity: "intermediate"
|
||||
|
||||
# Core dependencies
|
||||
dependencies:
|
||||
core_agents:
|
||||
- "architect" # Integrates with existing architect agent
|
||||
core_templates:
|
||||
- "architecture-tmpl.yaml" # May reference core architecture templates
|
||||
core_tasks:
|
||||
- "create-doc.md" # Uses core document creation task
|
||||
|
||||
# Expansion pack structure
|
||||
structure:
|
||||
agents:
|
||||
- "c4-architect.md"
|
||||
tasks:
|
||||
- "create-c4-context.md"
|
||||
- "create-c4-container.md"
|
||||
- "create-c4-component.md"
|
||||
- "generate-structurizr-dsl.md"
|
||||
- "validate-c4-model.md"
|
||||
- "create-structurizr-workspace.md"
|
||||
- "update-c4-diagram.md"
|
||||
- "export-c4-diagrams.md"
|
||||
- "review-c4-architecture.md"
|
||||
templates:
|
||||
- "c4-context-tmpl.yaml"
|
||||
- "c4-container-tmpl.yaml"
|
||||
- "c4-component-tmpl.yaml"
|
||||
- "structurizr-workspace-tmpl.yaml"
|
||||
checklists:
|
||||
- "c4-model-checklist.md"
|
||||
data:
|
||||
- "c4-model-guidelines.md"
|
||||
|
||||
# Installation configuration
|
||||
installation:
|
||||
target_directory: ".bmad-c4-architecture"
|
||||
merge_strategy: "copy" # Copy files to target directory
|
||||
backup_existing: true
|
||||
update_core_config: true
|
||||
|
||||
# Integration points with core BMad workflow
|
||||
integration:
|
||||
planning_phase:
|
||||
- "create-context" # Can be used during planning
|
||||
architecture_phase:
|
||||
- "create-container"
|
||||
- "create-component"
|
||||
- "generate-dsl"
|
||||
development_phase:
|
||||
- "update-diagram"
|
||||
- "validate-model"
|
||||
review_phase:
|
||||
- "review-architecture"
|
||||
- "export-diagrams"
|
||||
|
||||
# Agent team configurations
|
||||
teams:
|
||||
architecture_team:
|
||||
description: "Complete architecture team with C4 visualization"
|
||||
agents: ["architect", "c4-architect"]
|
||||
visualization_team:
|
||||
description: "Focused on architecture visualization and documentation"
|
||||
agents: ["c4-architect"]
|
||||
full_team:
|
||||
description: "Complete development team including C4 visualization"
|
||||
agents: ["analyst", "pm", "architect", "c4-architect", "dev", "qa"]
|
||||
|
||||
# External dependencies
|
||||
external_dependencies:
|
||||
tools:
|
||||
- "Structurizr Lite" # For diagram visualization
|
||||
- "Java 11+" # Required for Structurizr Lite
|
||||
services:
|
||||
- "Structurizr Cloud (optional)" # For cloud-based diagram management
|
||||
|
||||
# Configuration options
|
||||
config_options:
|
||||
structurizr_lite_url: "http://localhost:8080"
|
||||
default_theme: "default"
|
||||
export_formats: ["png", "svg", "pdf", "dsl"]
|
||||
auto_layout: true
|
||||
validation_strict: true
|
||||
|
||||
# Usage examples
|
||||
usage_examples:
|
||||
- "Create C4 context diagram for new system"
|
||||
- "Generate container diagram for microservices architecture"
|
||||
- "Create component diagram for complex service"
|
||||
- "Export diagrams for documentation"
|
||||
- "Validate architecture against C4 best practices"
|
||||
|
|
@ -0,0 +1,205 @@
|
|||
# C4 Model Guidelines
|
||||
|
||||
## Overview
|
||||
|
||||
The C4 model is a hierarchical approach to visualizing software architecture through four levels of abstraction.
|
||||
|
||||
## Level 1: System Context Diagram
|
||||
|
||||
- **Purpose**: Shows how the system fits into the world around it
|
||||
- **Audience**: Technical and non-technical people
|
||||
- **Elements**: Users, software systems, external systems
|
||||
- **Key Questions**:
|
||||
- Who uses the system?
|
||||
- What external systems does it interact with?
|
||||
- What are the main user goals?
|
||||
|
||||
## Level 2: Container Diagram
|
||||
|
||||
- **Purpose**: Zooms into the system boundary, showing high-level technical building blocks
|
||||
- **Audience**: Software developers and architects
|
||||
- **Elements**: Containers (applications, databases, file systems, etc.)
|
||||
- **Key Questions**:
|
||||
- What are the main functional areas?
|
||||
- What technology choices have been made?
|
||||
- How do containers communicate?
|
||||
|
||||
## Level 3: Component Diagram
|
||||
|
||||
- **Purpose**: Zooms into a container to show the components within it
|
||||
- **Audience**: Software developers
|
||||
- **Elements**: Components, interfaces, data models
|
||||
- **Key Questions**:
|
||||
- What are the main components?
|
||||
- How do components interact?
|
||||
- What are the key interfaces?
|
||||
|
||||
## Level 4: Code Diagram
|
||||
|
||||
- **Purpose**: Zooms into a component to show how it is implemented
|
||||
- **Audience**: Software developers
|
||||
- **Elements**: Classes, interfaces, packages
|
||||
- **Note**: Usually created using UML or similar tools
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Naming Conventions
|
||||
|
||||
- Use clear, descriptive names
|
||||
- Be consistent across all diagrams
|
||||
- Use business terminology where appropriate
|
||||
- Avoid technical jargon in context diagrams
|
||||
|
||||
### Relationship Labels
|
||||
|
||||
- Use active voice ("Uses", "Sends data to")
|
||||
- Be specific about protocols and technologies
|
||||
- Include data flow direction
|
||||
- Use consistent terminology
|
||||
|
||||
### Diagram Layout
|
||||
|
||||
- Use autolayout for consistency
|
||||
- Group related elements
|
||||
- Minimize crossing lines
|
||||
- Use appropriate colors and styling
|
||||
|
||||
### Technology Choices
|
||||
|
||||
- Be specific about technologies
|
||||
- Justify technology decisions
|
||||
- Consider scalability and maintainability
|
||||
- Document technology constraints
|
||||
|
||||
## Common Anti-Patterns
|
||||
|
||||
### Context Diagram
|
||||
|
||||
- ❌ Too many external systems
|
||||
- ❌ Missing key users
|
||||
- ❌ Unclear relationships
|
||||
- ❌ Technical details in context diagram
|
||||
|
||||
### Container Diagram
|
||||
|
||||
- ❌ Too many containers
|
||||
- ❌ Missing communication protocols
|
||||
- ❌ Unclear responsibilities
|
||||
- ❌ Missing security boundaries
|
||||
|
||||
### Component Diagram
|
||||
|
||||
- ❌ Too much detail
|
||||
- ❌ Missing interfaces
|
||||
- ❌ Unclear data flow
|
||||
- ❌ Missing error handling
|
||||
|
||||
## Structurizr DSL Best Practices
|
||||
|
||||
### Workspace Structure
|
||||
|
||||
```dsl
|
||||
workspace "Name" "Description" {
|
||||
model {
|
||||
// All model elements
|
||||
}
|
||||
views {
|
||||
// All views
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Element Definitions
|
||||
|
||||
- Always provide descriptions for elements
|
||||
- Use consistent naming conventions
|
||||
- Group related elements logically
|
||||
- Apply appropriate tags and properties
|
||||
|
||||
### Relationship Definitions
|
||||
|
||||
- Use descriptive labels
|
||||
- Include technology information
|
||||
- Specify data flow direction
|
||||
- Avoid circular dependencies
|
||||
|
||||
### View Configuration
|
||||
|
||||
- Use autolayout for consistency
|
||||
- Include all relevant elements
|
||||
- Apply appropriate themes
|
||||
- Test view layouts
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
### Context Diagram
|
||||
|
||||
- [ ] All key users are represented
|
||||
- [ ] All external systems are identified
|
||||
- [ ] Relationships are clearly defined
|
||||
- [ ] Technology choices are appropriate
|
||||
- [ ] Diagram is understandable to non-technical stakeholders
|
||||
|
||||
### Container Diagram
|
||||
|
||||
- [ ] All major components are represented
|
||||
- [ ] Technology choices are justified
|
||||
- [ ] Data flow is clear
|
||||
- [ ] Security boundaries are defined
|
||||
- [ ] Scalability considerations are addressed
|
||||
|
||||
### Component Diagram
|
||||
|
||||
- [ ] All major components are represented
|
||||
- [ ] Interfaces are clearly defined
|
||||
- [ ] Data flow is logical
|
||||
- [ ] Dependencies are minimal
|
||||
- [ ] Error handling is considered
|
||||
|
||||
## Common Issues and Solutions
|
||||
|
||||
### Issue: Too Many Elements
|
||||
|
||||
**Solution**: Focus on the most important elements and relationships. Use multiple diagrams if needed.
|
||||
|
||||
### Issue: Unclear Relationships
|
||||
|
||||
**Solution**: Use descriptive labels and include technology information. Show data flow direction.
|
||||
|
||||
### Issue: Inconsistent Naming
|
||||
|
||||
**Solution**: Establish naming conventions and apply them consistently across all diagrams.
|
||||
|
||||
### Issue: Missing Context
|
||||
|
||||
**Solution**: Ensure each diagram level provides appropriate context for its audience.
|
||||
|
||||
### Issue: Technical Details in Context Diagram
|
||||
|
||||
**Solution**: Keep context diagrams high-level and business-focused. Move technical details to container diagrams.
|
||||
|
||||
## Integration with Development Process
|
||||
|
||||
### Planning Phase
|
||||
|
||||
- Create context diagrams to understand system scope
|
||||
- Use diagrams for stakeholder communication
|
||||
- Validate requirements against architecture
|
||||
|
||||
### Design Phase
|
||||
|
||||
- Create container diagrams for technical design
|
||||
- Use component diagrams for detailed design
|
||||
- Validate design decisions
|
||||
|
||||
### Implementation Phase
|
||||
|
||||
- Keep diagrams updated with implementation
|
||||
- Use diagrams for developer onboarding
|
||||
- Document architectural decisions
|
||||
|
||||
### Maintenance Phase
|
||||
|
||||
- Regular diagram updates
|
||||
- Version control diagram changes
|
||||
- Use diagrams for impact analysis
|
||||
|
|
@ -0,0 +1,282 @@
|
|||
#!/bin/bash
|
||||
|
||||
# BMAD C4 Architecture Expansion Pack Installation Script
|
||||
# This script installs the C4 Architecture expansion pack into a BMAD-METHOD project
|
||||
|
||||
set -e
|
||||
|
||||
# Colors for output
|
||||
RED='\033[0;31m'
|
||||
GREEN='\033[0;32m'
|
||||
YELLOW='\033[1;33m'
|
||||
BLUE='\033[0;34m'
|
||||
NC='\033[0m' # No Color
|
||||
|
||||
# Configuration
|
||||
EXPANSION_PACK_NAME="bmad-c4-architecture"
|
||||
TARGET_DIR=".bmad-c4-architecture"
|
||||
SOURCE_DIR="$(dirname "$0")"
|
||||
|
||||
echo -e "${BLUE}🏛️ BMAD C4 Architecture Expansion Pack Installer${NC}"
|
||||
echo "=================================================="
|
||||
|
||||
# Check if we're in a BMAD-METHOD project
|
||||
if [ ! -f "package.json" ] || ! grep -q "bmad-method" package.json; then
|
||||
echo -e "${RED}❌ Error: This doesn't appear to be a BMAD-METHOD project.${NC}"
|
||||
echo "Please run this script from the root of a BMAD-METHOD project."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Check if expansion pack already exists
|
||||
if [ -d "$TARGET_DIR" ]; then
|
||||
echo -e "${YELLOW}⚠️ Expansion pack already exists at $TARGET_DIR${NC}"
|
||||
read -p "Do you want to overwrite it? (y/N): " -n 1 -r
|
||||
echo
|
||||
if [[ ! $REPLY =~ ^[Yy]$ ]]; then
|
||||
echo "Installation cancelled."
|
||||
exit 0
|
||||
fi
|
||||
echo -e "${YELLOW}Removing existing expansion pack...${NC}"
|
||||
rm -rf "$TARGET_DIR"
|
||||
fi
|
||||
|
||||
# Create target directory
|
||||
echo -e "${BLUE}📁 Creating target directory...${NC}"
|
||||
mkdir -p "$TARGET_DIR"
|
||||
|
||||
# Copy expansion pack files
|
||||
echo -e "${BLUE}📋 Copying expansion pack files...${NC}"
|
||||
cp -r "$SOURCE_DIR"/* "$TARGET_DIR/"
|
||||
|
||||
# Remove the install script from target
|
||||
rm -f "$TARGET_DIR/install.sh"
|
||||
|
||||
# Update core configuration
|
||||
echo -e "${BLUE}⚙️ Updating core configuration...${NC}"
|
||||
if [ -f ".bmad-core/core-config.yaml" ]; then
|
||||
# Backup existing config
|
||||
cp ".bmad-core/core-config.yaml" ".bmad-core/core-config.yaml.backup"
|
||||
echo -e "${YELLOW}📋 Backed up existing core-config.yaml${NC}"
|
||||
fi
|
||||
|
||||
# Create or update core config to include C4 architecture
|
||||
cat > ".bmad-core/core-config.yaml" << EOF
|
||||
# BMAD Core Configuration
|
||||
# This file is automatically generated by the C4 Architecture expansion pack
|
||||
|
||||
# Developer context files
|
||||
devLoadAlwaysFiles:
|
||||
- docs/architecture/coding-standards.md
|
||||
- docs/architecture/tech-stack.md
|
||||
- docs/architecture/project-structure.md
|
||||
|
||||
# Expansion pack configurations
|
||||
expansionPacks:
|
||||
- name: "c4-architecture"
|
||||
enabled: true
|
||||
config: ".bmad-c4-architecture/config.yaml"
|
||||
|
||||
# C4 Architecture specific settings
|
||||
c4Architecture:
|
||||
structurizrLiteUrl: "http://localhost:8080"
|
||||
defaultTheme: "default"
|
||||
exportFormats: ["png", "svg", "pdf", "dsl"]
|
||||
autoLayout: true
|
||||
validationStrict: true
|
||||
EOF
|
||||
|
||||
# Create example technical preferences
|
||||
if [ ! -f ".bmad-c4-architecture/data/technical-preferences.md" ]; then
|
||||
echo -e "${BLUE}📝 Creating example technical preferences...${NC}"
|
||||
cat > ".bmad-c4-architecture/data/technical-preferences.md" << EOF
|
||||
# Technical Preferences for C4 Architecture
|
||||
|
||||
## Preferred Technologies
|
||||
|
||||
### Frontend
|
||||
- React, Vue.js, Angular
|
||||
- TypeScript preferred over JavaScript
|
||||
- Tailwind CSS for styling
|
||||
|
||||
### Backend
|
||||
- Node.js, Python, Java, Go
|
||||
- RESTful APIs preferred
|
||||
- GraphQL for complex data requirements
|
||||
|
||||
### Databases
|
||||
- PostgreSQL for relational data
|
||||
- MongoDB for document storage
|
||||
- Redis for caching
|
||||
|
||||
### Cloud Platforms
|
||||
- AWS, Azure, Google Cloud
|
||||
- Docker for containerization
|
||||
- Kubernetes for orchestration
|
||||
|
||||
## Architecture Patterns
|
||||
|
||||
### Microservices
|
||||
- Domain-driven design
|
||||
- Event-driven architecture
|
||||
- API-first approach
|
||||
|
||||
### Security
|
||||
- OAuth 2.0 / OpenID Connect
|
||||
- JWT tokens
|
||||
- HTTPS everywhere
|
||||
|
||||
## Diagram Preferences
|
||||
|
||||
### Styling
|
||||
- Consistent color scheme
|
||||
- Clear, readable fonts
|
||||
- Minimal, clean layouts
|
||||
|
||||
### Naming
|
||||
- Business terminology in context diagrams
|
||||
- Technical terminology in container/component diagrams
|
||||
- Consistent naming conventions
|
||||
EOF
|
||||
fi
|
||||
|
||||
# Check for Structurizr Lite dependencies
|
||||
echo -e "${BLUE}🔍 Checking for Structurizr Lite dependencies...${NC}"
|
||||
|
||||
# Check for Docker (recommended)
|
||||
if command -v docker &> /dev/null; then
|
||||
echo -e "${GREEN}✅ Docker found - recommended for Structurizr Lite${NC}"
|
||||
echo -e "${BLUE}💡 To start Structurizr Lite with Docker:${NC}"
|
||||
echo " docker pull structurizr/lite"
|
||||
echo " docker run -it --rm -p 8080:8080 -v ~/structurizr:/usr/local/structurizr structurizr/lite"
|
||||
else
|
||||
echo -e "${YELLOW}⚠️ Docker not found. You can install Docker or use Java 17+ instead.${NC}"
|
||||
fi
|
||||
|
||||
# Check for Java (alternative)
|
||||
if command -v java &> /dev/null; then
|
||||
JAVA_VERSION=$(java -version 2>&1 | head -n 1 | cut -d'"' -f2 | cut -d'.' -f1)
|
||||
if [ "$JAVA_VERSION" -lt 17 ]; then
|
||||
echo -e "${YELLOW}⚠️ Java version $JAVA_VERSION found. Structurizr Lite Spring Boot requires Java 17+.${NC}"
|
||||
echo "Please upgrade to Java 17 or later, or use Docker instead."
|
||||
echo "Visit: https://adoptium.net/"
|
||||
else
|
||||
echo -e "${GREEN}✅ Java $JAVA_VERSION found - compatible with Structurizr Lite Spring Boot${NC}"
|
||||
fi
|
||||
else
|
||||
echo -e "${YELLOW}⚠️ Java not found. Install Java 17+ or use Docker instead.${NC}"
|
||||
echo "Visit: https://adoptium.net/"
|
||||
fi
|
||||
|
||||
# Create example workspace
|
||||
echo -e "${BLUE}📄 Creating example workspace...${NC}"
|
||||
cat > ".bmad-c4-architecture/examples/example-workspace.dsl" << EOF
|
||||
workspace "Example E-commerce Platform" "A sample e-commerce platform architecture" {
|
||||
model {
|
||||
customer = person "Customer" "A customer of the e-commerce platform"
|
||||
admin = person "Administrator" "An administrator of the e-commerce platform"
|
||||
|
||||
ecommerce = softwareSystem "E-commerce Platform" "Allows customers to browse and purchase products" {
|
||||
webApp = container "Web Application" "Provides the user interface" "React, TypeScript" {
|
||||
customer -> this "Uses" "HTTPS"
|
||||
admin -> this "Uses" "HTTPS"
|
||||
}
|
||||
|
||||
api = container "API" "Provides business logic" "Node.js, Express" {
|
||||
webApp -> this "Makes API calls" "HTTPS/REST"
|
||||
}
|
||||
|
||||
database = container "Database" "Stores data" "PostgreSQL" {
|
||||
api -> this "Reads from and writes to" "SQL"
|
||||
}
|
||||
|
||||
paymentGateway = softwareSystem "Payment Gateway" "Processes payments" "External"
|
||||
api -> paymentGateway "Sends payment requests" "HTTPS/API"
|
||||
}
|
||||
}
|
||||
|
||||
views {
|
||||
systemContext ecommerce {
|
||||
include *
|
||||
autolayout lr
|
||||
}
|
||||
|
||||
container ecommerce {
|
||||
include *
|
||||
autolayout lr
|
||||
}
|
||||
|
||||
theme default
|
||||
}
|
||||
}
|
||||
EOF
|
||||
|
||||
# Create quick start guide
|
||||
echo -e "${BLUE}📚 Creating quick start guide...${NC}"
|
||||
cat > ".bmad-c4-architecture/QUICKSTART.md" << EOF
|
||||
# C4 Architecture Quick Start Guide
|
||||
|
||||
## 1. Start Structurizr Lite (Optional)
|
||||
\`\`\`bash
|
||||
# Download and run Structurizr Lite
|
||||
git clone https://github.com/structurizr/lite.git
|
||||
cd lite
|
||||
./gradlew bootRun
|
||||
# Access at http://localhost:8080
|
||||
\`\`\`
|
||||
|
||||
## 2. Use the C4 Architect Agent
|
||||
\`\`\`bash
|
||||
# In your IDE
|
||||
@c4-architect
|
||||
*help
|
||||
\`\`\`
|
||||
|
||||
## 3. Create Your First Diagram
|
||||
\`\`\`bash
|
||||
# Create a context diagram
|
||||
*create-context
|
||||
|
||||
# Follow the interactive prompts to define:
|
||||
# - System name and description
|
||||
# - Users and their goals
|
||||
# - External systems
|
||||
# - Key relationships
|
||||
\`\`\`
|
||||
|
||||
## 4. Generate Complete Workspace
|
||||
\`\`\`bash
|
||||
# Generate full Structurizr DSL
|
||||
*generate-dsl
|
||||
|
||||
# Validate your model
|
||||
*validate-model
|
||||
|
||||
# Export diagrams
|
||||
*export-diagrams
|
||||
\`\`\`
|
||||
|
||||
## 5. Example Files
|
||||
- \`examples/example-workspace.dsl\` - Sample Structurizr DSL
|
||||
- \`data/technical-preferences.md\` - Your technical preferences
|
||||
- \`README.md\` - Complete documentation
|
||||
|
||||
## Next Steps
|
||||
1. Read the full README.md for comprehensive documentation
|
||||
2. Customize technical-preferences.md for your project
|
||||
3. Start creating your architecture diagrams!
|
||||
EOF
|
||||
|
||||
# Final success message
|
||||
echo ""
|
||||
echo -e "${GREEN}🎉 C4 Architecture Expansion Pack installed successfully!${NC}"
|
||||
echo ""
|
||||
echo -e "${BLUE}📁 Installation location: $TARGET_DIR${NC}"
|
||||
echo -e "${BLUE}📚 Quick start guide: $TARGET_DIR/QUICKSTART.md${NC}"
|
||||
echo -e "${BLUE}📖 Full documentation: $TARGET_DIR/README.md${NC}"
|
||||
echo ""
|
||||
echo -e "${YELLOW}🚀 Next steps:${NC}"
|
||||
echo "1. Read the quick start guide: $TARGET_DIR/QUICKSTART.md"
|
||||
echo "2. Start Structurizr Lite (optional): http://localhost:8080"
|
||||
echo "3. Use the C4 Architect agent in your IDE: @c4-architect"
|
||||
echo ""
|
||||
echo -e "${GREEN}Happy architecting! 🏛️${NC}"
|
||||
|
|
@ -0,0 +1,78 @@
|
|||
# Create C4 Component Diagram
|
||||
|
||||
## Purpose
|
||||
|
||||
Create a C4 Component diagram (Level 3) that zooms into a container to show the components within it.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Completed container diagram
|
||||
- Detailed component requirements
|
||||
- Interface specifications
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Identify Components
|
||||
|
||||
- Controllers and handlers
|
||||
- Services and business logic
|
||||
- Data access layers
|
||||
- External interfaces
|
||||
- Utilities and shared libraries
|
||||
|
||||
### 2. Define Component Properties
|
||||
|
||||
- Technology stack
|
||||
- Responsibilities
|
||||
- Interfaces and APIs
|
||||
- Dependencies
|
||||
|
||||
### 3. Define Relationships
|
||||
|
||||
- Component-to-component communication
|
||||
- Data flow patterns
|
||||
- Interface contracts
|
||||
- Error handling
|
||||
|
||||
### 4. Create DSL Structure
|
||||
|
||||
```dsl
|
||||
container = container "Container Name" "Container description" "Technology" {
|
||||
controller = component "Controller" "Handles HTTP requests" "Spring MVC" {
|
||||
user -> this "Uses" "HTTPS"
|
||||
}
|
||||
|
||||
service = component "Service" "Business logic" "Java" {
|
||||
controller -> this "Calls" "Java"
|
||||
}
|
||||
|
||||
repository = component "Repository" "Data access" "JPA" {
|
||||
service -> this "Uses" "Java"
|
||||
}
|
||||
|
||||
database = softwareSystem "Database" "Data storage" "External"
|
||||
repository -> database "Reads from and writes to" "JDBC"
|
||||
}
|
||||
```
|
||||
|
||||
### 5. Validation
|
||||
|
||||
- [ ] All major components are represented
|
||||
- [ ] Interfaces are clearly defined
|
||||
- [ ] Data flow is logical
|
||||
- [ ] Dependencies are minimal
|
||||
- [ ] Error handling is considered
|
||||
|
||||
## Output
|
||||
|
||||
- Updated Structurizr DSL with component definitions
|
||||
- Component diagram visualization
|
||||
- Interface documentation
|
||||
|
||||
## Elicitation Questions
|
||||
|
||||
1. What are the main components within this container?
|
||||
2. How do the components interact with each other?
|
||||
3. What are the key interfaces and APIs?
|
||||
4. What are the data flow patterns?
|
||||
5. What error handling mechanisms are needed?
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
# Create C4 Container Diagram
|
||||
|
||||
## Purpose
|
||||
|
||||
Create a C4 Container diagram (Level 2) that zooms into the system boundary, showing high-level technical building blocks.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Completed context diagram
|
||||
- Technology stack decisions
|
||||
- High-level architecture patterns
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Identify Containers
|
||||
|
||||
- Web applications
|
||||
- Mobile applications
|
||||
- Desktop applications
|
||||
- APIs and microservices
|
||||
- Databases
|
||||
- File systems
|
||||
- External service interfaces
|
||||
|
||||
### 2. Define Container Properties
|
||||
|
||||
- Technology stack
|
||||
- Responsibilities
|
||||
- Data storage requirements
|
||||
- Communication protocols
|
||||
|
||||
### 3. Define Relationships
|
||||
|
||||
- Container-to-container communication
|
||||
- Data flow patterns
|
||||
- Security boundaries
|
||||
- Deployment considerations
|
||||
|
||||
### 4. Create DSL Structure
|
||||
|
||||
```dsl
|
||||
softwareSystem = softwareSystem "System Name" "System description" {
|
||||
webApp = container "Web Application" "Handles user interactions" "React, Node.js" {
|
||||
user -> this "Uses" "HTTPS"
|
||||
}
|
||||
|
||||
api = container "API" "Provides business logic" "Java, Spring Boot" {
|
||||
webApp -> this "Makes API calls" "HTTPS/REST"
|
||||
}
|
||||
|
||||
database = container "Database" "Stores data" "PostgreSQL" {
|
||||
api -> this "Reads from and writes to" "JDBC"
|
||||
}
|
||||
|
||||
externalApi = softwareSystem "External API" "External service" "External"
|
||||
api -> externalApi "Sends requests" "HTTPS/REST"
|
||||
}
|
||||
```
|
||||
|
||||
### 5. Validation
|
||||
|
||||
- [ ] All major components are represented
|
||||
- [ ] Technology choices are justified
|
||||
- [ ] Data flow is clear
|
||||
- [ ] Security boundaries are defined
|
||||
- [ ] Scalability considerations are addressed
|
||||
|
||||
## Output
|
||||
|
||||
- Updated Structurizr DSL with container definitions
|
||||
- Container diagram visualization
|
||||
- Technology decision documentation
|
||||
|
||||
## Elicitation Questions
|
||||
|
||||
1. What are the main functional areas of the system?
|
||||
2. What technology stack will be used for each container?
|
||||
3. How do the containers communicate with each other?
|
||||
4. What are the data storage requirements?
|
||||
5. What security boundaries need to be considered?
|
||||
|
|
@ -0,0 +1,85 @@
|
|||
# Create C4 Context Diagram
|
||||
|
||||
## Purpose
|
||||
|
||||
Create a C4 Context diagram (Level 1) that shows how the system fits into the world around it.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- System name and description
|
||||
- Key users/actors
|
||||
- External systems and dependencies
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Gather Information
|
||||
|
||||
- System name and purpose
|
||||
- Primary users and their goals
|
||||
- External systems the software system interacts with
|
||||
- Business context and constraints
|
||||
|
||||
### 2. Define Elements
|
||||
|
||||
- **Person**: End users, administrators, external users
|
||||
- **Software System**: The system being designed
|
||||
- **External Systems**: Third-party services, legacy systems, external APIs
|
||||
|
||||
### 3. Define Relationships
|
||||
|
||||
- User interactions with the system
|
||||
- System interactions with external systems
|
||||
- Data flow directions
|
||||
|
||||
### 4. Create DSL Structure
|
||||
|
||||
```dsl
|
||||
workspace "System Name" "System description" {
|
||||
model {
|
||||
// Define persons
|
||||
user = person "User Name" "User description"
|
||||
|
||||
// Define the software system
|
||||
softwareSystem = softwareSystem "System Name" "System description" {
|
||||
// Internal containers will be defined in container diagram
|
||||
}
|
||||
|
||||
// Define external systems
|
||||
externalSystem = softwareSystem "External System" "External system description" "External"
|
||||
|
||||
// Define relationships
|
||||
user -> softwareSystem "Uses" "HTTPS"
|
||||
softwareSystem -> externalSystem "Sends data" "HTTPS/API"
|
||||
}
|
||||
|
||||
views {
|
||||
systemContext softwareSystem {
|
||||
include *
|
||||
autolayout lr
|
||||
}
|
||||
theme default
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 5. Validation
|
||||
|
||||
- [ ] All key users are represented
|
||||
- [ ] All external systems are identified
|
||||
- [ ] Relationships are clearly defined
|
||||
- [ ] Diagram follows C4 model principles
|
||||
- [ ] Technology choices are appropriate
|
||||
|
||||
## Output
|
||||
|
||||
- Structurizr DSL file for context diagram
|
||||
- Visual diagram (if Structurizr Lite is available)
|
||||
- Documentation of design decisions
|
||||
|
||||
## Elicitation Questions
|
||||
|
||||
1. What is the name and purpose of the system?
|
||||
2. Who are the primary users of this system?
|
||||
3. What external systems does this system need to interact with?
|
||||
4. What are the main user goals when using this system?
|
||||
5. What business context or constraints should be considered?
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
# Create Structurizr Workspace
|
||||
|
||||
## Purpose
|
||||
|
||||
Create a new Structurizr workspace from scratch with proper structure and configuration.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Workspace requirements
|
||||
- Initial system information
|
||||
- Target audience definition
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Define Workspace Structure
|
||||
|
||||
- Set workspace name and description
|
||||
- Define initial model structure
|
||||
- Configure basic views
|
||||
- Set up styling and theming
|
||||
|
||||
### 2. Create Initial Elements
|
||||
|
||||
- Define primary users
|
||||
- Create main software system
|
||||
- Add key external systems
|
||||
- Establish basic relationships
|
||||
|
||||
### 3. Configure Views
|
||||
|
||||
- System context view
|
||||
- Container views
|
||||
- Component views
|
||||
- Deployment views (if needed)
|
||||
|
||||
### 4. Apply Styling
|
||||
|
||||
- Set consistent colors
|
||||
- Configure element shapes
|
||||
- Define relationship styles
|
||||
- Apply appropriate theme
|
||||
|
||||
### 5. Generate Initial DSL
|
||||
|
||||
```dsl
|
||||
workspace "New Workspace" "Description" {
|
||||
model {
|
||||
user = person "User" "End user"
|
||||
softwareSystem = softwareSystem "System" "Main system" {
|
||||
// Initial containers will be added
|
||||
}
|
||||
}
|
||||
|
||||
views {
|
||||
systemContext softwareSystem {
|
||||
include *
|
||||
autolayout lr
|
||||
}
|
||||
theme default
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
- Complete Structurizr DSL workspace file
|
||||
- Workspace configuration documentation
|
||||
- Next steps guidance
|
||||
|
||||
## Elicitation Questions
|
||||
|
||||
1. What is the name and purpose of the workspace?
|
||||
2. Who is the target audience for the diagrams?
|
||||
3. What is the initial scope of the system?
|
||||
4. Are there any specific styling requirements?
|
||||
5. What views should be included initially?
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
# Export C4 Diagrams
|
||||
|
||||
## Purpose
|
||||
|
||||
Export C4 diagrams in various formats for documentation, presentation, or sharing.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Complete C4 model
|
||||
- Target export formats
|
||||
- Export requirements
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Prepare Diagrams
|
||||
|
||||
- Ensure all views are properly configured
|
||||
- Validate diagram layouts
|
||||
- Apply consistent styling
|
||||
- Check for completeness
|
||||
|
||||
### 2. Select Export Formats
|
||||
|
||||
- PNG/JPEG for images
|
||||
- SVG for scalable graphics
|
||||
- PDF for documentation
|
||||
- Mermaid for text-based diagrams
|
||||
|
||||
### 3. Configure Export Settings
|
||||
|
||||
- Set image resolution
|
||||
- Choose color schemes
|
||||
- Configure layout options
|
||||
- Set file naming conventions
|
||||
|
||||
### 4. Generate Exports
|
||||
|
||||
- Create image files
|
||||
- Generate documentation
|
||||
- Package for distribution
|
||||
- Validate output quality
|
||||
|
||||
### 5. Organize Output
|
||||
|
||||
- Create organized folder structure
|
||||
- Name files descriptively
|
||||
- Include metadata
|
||||
- Provide usage instructions
|
||||
|
||||
## Export Formats
|
||||
|
||||
- **PNG**: High-quality images for presentations
|
||||
- **SVG**: Scalable vector graphics for web
|
||||
- **PDF**: Documentation-ready format
|
||||
- **Mermaid**: Text-based diagram format
|
||||
- **DSL**: Source format for Structurizr
|
||||
|
||||
## Output
|
||||
|
||||
- Exported diagram files
|
||||
- Documentation package
|
||||
- Usage instructions
|
||||
- File organization guide
|
||||
|
||||
## Elicitation Questions
|
||||
|
||||
1. What formats are needed for export?
|
||||
2. What resolution or quality settings are required?
|
||||
3. How should the files be organized?
|
||||
4. Are there any specific naming conventions?
|
||||
5. What metadata should be included?
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
# Generate Structurizr DSL
|
||||
|
||||
## Purpose
|
||||
|
||||
Generate a complete Structurizr DSL workspace from existing C4 model information.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- C4 model elements defined
|
||||
- Relationships mapped
|
||||
- View requirements specified
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Gather Model Information
|
||||
|
||||
- All persons, systems, containers, and components
|
||||
- All relationships and their properties
|
||||
- View requirements and styling preferences
|
||||
- Workspace metadata
|
||||
|
||||
### 2. Structure the DSL
|
||||
|
||||
- Create workspace header with name and description
|
||||
- Define model section with all elements
|
||||
- Define views section with all diagrams
|
||||
- Apply styling and theming
|
||||
|
||||
### 3. Generate Complete DSL
|
||||
|
||||
```dsl
|
||||
workspace "Workspace Name" "Description" {
|
||||
model {
|
||||
// All model elements
|
||||
user = person "User" "End user"
|
||||
softwareSystem = softwareSystem "System" "Main system" {
|
||||
// Containers and components
|
||||
}
|
||||
}
|
||||
|
||||
views {
|
||||
// All views
|
||||
systemContext softwareSystem {
|
||||
include *
|
||||
autolayout lr
|
||||
}
|
||||
container softwareSystem {
|
||||
include *
|
||||
autolayout lr
|
||||
}
|
||||
component container {
|
||||
include *
|
||||
autolayout lr
|
||||
}
|
||||
theme default
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Validation
|
||||
|
||||
- [ ] DSL syntax is correct
|
||||
- [ ] All elements are properly defined
|
||||
- [ ] All relationships are valid
|
||||
- [ ] Views are properly configured
|
||||
- [ ] Styling is consistent
|
||||
|
||||
## Output
|
||||
|
||||
- Complete Structurizr DSL file
|
||||
- Validation report
|
||||
- Usage instructions
|
||||
|
||||
## Elicitation Questions
|
||||
|
||||
1. What should be the workspace name and description?
|
||||
2. Are there any specific styling requirements?
|
||||
3. What views need to be included?
|
||||
4. Are there any custom properties or tags needed?
|
||||
5. What deployment information should be included?
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
# Review C4 Architecture
|
||||
|
||||
## Purpose
|
||||
|
||||
Review and suggest improvements to C4 architecture diagrams for clarity, completeness, and best practices.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Complete C4 model
|
||||
- Review criteria
|
||||
- Target audience information
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Analyze Architecture
|
||||
|
||||
- Review all diagram levels
|
||||
- Assess element completeness
|
||||
- Check relationship clarity
|
||||
- Evaluate naming consistency
|
||||
|
||||
### 2. Apply Best Practices
|
||||
|
||||
- Verify C4 model hierarchy
|
||||
- Check abstraction levels
|
||||
- Validate technology choices
|
||||
- Assess stakeholder communication
|
||||
|
||||
### 3. Identify Issues
|
||||
|
||||
- Find missing elements
|
||||
- Identify unclear relationships
|
||||
- Spot naming inconsistencies
|
||||
- Detect anti-patterns
|
||||
|
||||
### 4. Generate Recommendations
|
||||
|
||||
- Suggest improvements
|
||||
- Provide alternatives
|
||||
- Recommend additions
|
||||
- Suggest removals
|
||||
|
||||
### 5. Create Review Report
|
||||
|
||||
- Document findings
|
||||
- Prioritize recommendations
|
||||
- Provide implementation guidance
|
||||
- Include examples
|
||||
|
||||
## Review Areas
|
||||
|
||||
- **Completeness**: All necessary elements present
|
||||
- **Clarity**: Clear and understandable diagrams
|
||||
- **Consistency**: Consistent naming and styling
|
||||
- **Hierarchy**: Proper C4 model levels
|
||||
- **Relationships**: Clear and logical connections
|
||||
- **Technology**: Appropriate technology choices
|
||||
|
||||
## Output
|
||||
|
||||
- Detailed review report
|
||||
- Prioritized recommendations
|
||||
- Implementation suggestions
|
||||
- Updated diagrams (if requested)
|
||||
|
||||
## Elicitation Questions
|
||||
|
||||
1. What specific aspects should be reviewed?
|
||||
2. Who is the target audience for the diagrams?
|
||||
3. Are there any specific concerns or issues?
|
||||
4. What level of detail is required in the review?
|
||||
5. Should the review focus on any particular areas?
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
# Update C4 Diagram
|
||||
|
||||
## Purpose
|
||||
|
||||
Update existing C4 diagram with new elements, relationships, or modifications.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Existing C4 model
|
||||
- Change requirements
|
||||
- Updated system information
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Analyze Current Model
|
||||
|
||||
- Review existing elements
|
||||
- Identify areas for change
|
||||
- Assess impact of modifications
|
||||
- Plan update strategy
|
||||
|
||||
### 2. Implement Changes
|
||||
|
||||
- Add new elements
|
||||
- Modify existing elements
|
||||
- Update relationships
|
||||
- Adjust views and styling
|
||||
|
||||
### 3. Validate Changes
|
||||
|
||||
- Check syntax correctness
|
||||
- Verify consistency
|
||||
- Test view layouts
|
||||
- Ensure completeness
|
||||
|
||||
### 4. Update Documentation
|
||||
|
||||
- Document changes made
|
||||
- Update element descriptions
|
||||
- Revise relationship labels
|
||||
- Update view configurations
|
||||
|
||||
### 5. Generate Updated DSL
|
||||
|
||||
- Create updated DSL file
|
||||
- Preserve existing structure
|
||||
- Apply new changes
|
||||
- Maintain consistency
|
||||
|
||||
## Change Types
|
||||
|
||||
- **Add Elements**: New persons, systems, containers, components
|
||||
- **Modify Elements**: Update descriptions, technologies, properties
|
||||
- **Update Relationships**: Change connections, labels, technologies
|
||||
- **Adjust Views**: Modify layouts, add/remove elements
|
||||
- **Apply Styling**: Update colors, shapes, themes
|
||||
|
||||
## Output
|
||||
|
||||
- Updated Structurizr DSL file
|
||||
- Change log documentation
|
||||
- Validation report
|
||||
|
||||
## Elicitation Questions
|
||||
|
||||
1. What specific changes need to be made?
|
||||
2. Are there any elements to remove or modify?
|
||||
3. What new relationships need to be added?
|
||||
4. Should any views be updated or added?
|
||||
5. Are there any styling changes required?
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
# Validate C4 Model
|
||||
|
||||
## Purpose
|
||||
|
||||
Validate C4 model consistency, completeness, and adherence to best practices.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- C4 model elements defined
|
||||
- Relationships mapped
|
||||
- DSL generated
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Syntax Validation
|
||||
|
||||
- Check DSL syntax correctness
|
||||
- Validate element definitions
|
||||
- Verify relationship syntax
|
||||
- Check view configurations
|
||||
|
||||
### 2. Consistency Checks
|
||||
|
||||
- Ensure all referenced elements exist
|
||||
- Validate relationship directions
|
||||
- Check for circular dependencies
|
||||
- Verify naming conventions
|
||||
|
||||
### 3. Completeness Review
|
||||
|
||||
- All key users represented
|
||||
- All external systems identified
|
||||
- All major components included
|
||||
- All critical relationships mapped
|
||||
|
||||
### 4. Best Practices Review
|
||||
|
||||
- C4 model hierarchy maintained
|
||||
- Appropriate abstraction levels
|
||||
- Clear and descriptive names
|
||||
- Consistent styling
|
||||
|
||||
### 5. Generate Validation Report
|
||||
|
||||
- List all issues found
|
||||
- Provide recommendations
|
||||
- Suggest improvements
|
||||
- Rate overall quality
|
||||
|
||||
## Validation Checklist
|
||||
|
||||
- [ ] DSL syntax is valid
|
||||
- [ ] All elements have proper descriptions
|
||||
- [ ] All relationships are bidirectional where appropriate
|
||||
- [ ] No orphaned elements
|
||||
- [ ] Consistent naming conventions
|
||||
- [ ] Appropriate technology labels
|
||||
- [ ] Clear view layouts
|
||||
- [ ] Proper abstraction levels maintained
|
||||
|
||||
## Output
|
||||
|
||||
- Validation report with issues and recommendations
|
||||
- Corrected DSL if issues found
|
||||
- Quality score and improvement suggestions
|
||||
|
||||
## Elicitation Questions
|
||||
|
||||
1. What specific validation criteria should be applied?
|
||||
2. Are there any custom naming conventions to check?
|
||||
3. What quality thresholds should be used?
|
||||
4. Are there any specific anti-patterns to avoid?
|
||||
5. What level of detail is required in the validation report?
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
name: "C4 Component Diagram Template"
|
||||
description: "Template for creating C4 Component diagrams using Structurizr DSL"
|
||||
version: "1.0"
|
||||
|
||||
sections:
|
||||
- id: container-context
|
||||
title: "Container Context"
|
||||
instruction: "Reference the container from container diagram"
|
||||
fields:
|
||||
- id: container-name
|
||||
title: "Container Name"
|
||||
type: "text"
|
||||
required: true
|
||||
placeholder: "Must match a container from container diagram"
|
||||
- id: container-description
|
||||
title: "Container Description"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "Brief description of the container"
|
||||
|
||||
- id: components
|
||||
title: "Components"
|
||||
instruction: "Define the components within the container"
|
||||
fields:
|
||||
- id: controllers
|
||||
title: "Controllers and Handlers"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List controllers (e.g., UserController, OrderController)"
|
||||
- id: services
|
||||
title: "Services and Business Logic"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List services (e.g., UserService, PaymentService)"
|
||||
- id: repositories
|
||||
title: "Data Access Layers"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List repositories (e.g., UserRepository, OrderRepository)"
|
||||
- id: external-interfaces
|
||||
title: "External Interfaces"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List external interfaces (e.g., PaymentGateway, EmailService)"
|
||||
- id: utilities
|
||||
title: "Utilities and Shared Libraries"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List utilities (e.g., Logger, Validator, Cache)"
|
||||
|
||||
- id: technologies
|
||||
title: "Component Technologies"
|
||||
instruction: "Specify technologies for each component type"
|
||||
fields:
|
||||
- id: controller-tech
|
||||
title: "Controller Technologies"
|
||||
type: "textarea"
|
||||
required: false
|
||||
placeholder: "Technologies for controllers (e.g., Spring MVC, Express.js)"
|
||||
- id: service-tech
|
||||
title: "Service Technologies"
|
||||
type: "textarea"
|
||||
required: false
|
||||
placeholder: "Technologies for services (e.g., Java, Node.js, Python)"
|
||||
- id: data-tech
|
||||
title: "Data Access Technologies"
|
||||
type: "textarea"
|
||||
required: false
|
||||
placeholder: "Technologies for data access (e.g., JPA, Hibernate, Mongoose)"
|
||||
|
||||
- id: relationships
|
||||
title: "Component Relationships"
|
||||
instruction: "Define how components interact"
|
||||
fields:
|
||||
- id: component-interactions
|
||||
title: "Component Interactions"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "How do components interact? (e.g., method calls, events)"
|
||||
- id: data-flow
|
||||
title: "Data Flow"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "How does data flow between components?"
|
||||
- id: interfaces
|
||||
title: "Key Interfaces"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "What are the key interfaces and APIs?"
|
||||
|
||||
- id: llm-instructions
|
||||
title: "LLM Instructions"
|
||||
instruction: "AI processing instructions for generating the DSL"
|
||||
content: |
|
||||
Based on the provided information, generate a complete Structurizr DSL workspace that creates a C4 Component diagram. Follow these guidelines:
|
||||
|
||||
1. Use the container name and description from the container diagram
|
||||
2. Create component elements for each identified component
|
||||
3. Specify appropriate technologies for each component
|
||||
4. Define relationships between components with proper technology labels
|
||||
5. Include relationships to external systems and databases
|
||||
6. Create a component view that shows all components within the container
|
||||
7. Apply autolayout for better diagram appearance
|
||||
8. Use the default theme
|
||||
|
||||
The DSL should be complete and ready to use with Structurizr Lite.
|
||||
|
|
@ -0,0 +1,107 @@
|
|||
name: "C4 Container Diagram Template"
|
||||
description: "Template for creating C4 Container diagrams using Structurizr DSL"
|
||||
version: "1.0"
|
||||
|
||||
sections:
|
||||
- id: system-context
|
||||
title: "System Context"
|
||||
instruction: "Reference the existing system from context diagram"
|
||||
fields:
|
||||
- id: system-name
|
||||
title: "System Name"
|
||||
type: "text"
|
||||
required: true
|
||||
placeholder: "Must match the system from context diagram"
|
||||
- id: system-description
|
||||
title: "System Description"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "Brief description of the system"
|
||||
|
||||
- id: containers
|
||||
title: "Containers"
|
||||
instruction: "Define the high-level technical building blocks"
|
||||
fields:
|
||||
- id: web-applications
|
||||
title: "Web Applications"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List web applications (e.g., React SPA, Angular App)"
|
||||
- id: mobile-applications
|
||||
title: "Mobile Applications"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List mobile applications (e.g., iOS App, Android App)"
|
||||
- id: apis
|
||||
title: "APIs and Services"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List APIs and microservices (e.g., REST API, GraphQL API)"
|
||||
- id: databases
|
||||
title: "Databases"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List databases (e.g., PostgreSQL, MongoDB, Redis)"
|
||||
- id: file-systems
|
||||
title: "File Systems"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List file systems (e.g., S3, Azure Blob, Local Storage)"
|
||||
|
||||
- id: technologies
|
||||
title: "Technology Stack"
|
||||
instruction: "Specify technologies for each container"
|
||||
fields:
|
||||
- id: frontend-tech
|
||||
title: "Frontend Technologies"
|
||||
type: "textarea"
|
||||
required: false
|
||||
placeholder: "Technologies for web and mobile applications"
|
||||
- id: backend-tech
|
||||
title: "Backend Technologies"
|
||||
type: "textarea"
|
||||
required: false
|
||||
placeholder: "Technologies for APIs and services"
|
||||
- id: data-tech
|
||||
title: "Data Technologies"
|
||||
type: "textarea"
|
||||
required: false
|
||||
placeholder: "Technologies for databases and storage"
|
||||
|
||||
- id: relationships
|
||||
title: "Container Relationships"
|
||||
instruction: "Define how containers communicate"
|
||||
fields:
|
||||
- id: communication-patterns
|
||||
title: "Communication Patterns"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "How do containers communicate? (e.g., REST API, Message Queue)"
|
||||
- id: data-flow
|
||||
title: "Data Flow"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "How does data flow between containers?"
|
||||
- id: security-boundaries
|
||||
title: "Security Boundaries"
|
||||
type: "textarea"
|
||||
required: false
|
||||
placeholder: "What security boundaries exist between containers?"
|
||||
|
||||
- id: llm-instructions
|
||||
title: "LLM Instructions"
|
||||
instruction: "AI processing instructions for generating the DSL"
|
||||
content: |
|
||||
Based on the provided information, generate a complete Structurizr DSL workspace that creates a C4 Container diagram. Follow these guidelines:
|
||||
|
||||
1. Use the system name and description from the context diagram
|
||||
2. Create container elements for each identified container
|
||||
3. Specify appropriate technologies for each container
|
||||
4. Define relationships between containers with proper technology labels
|
||||
5. Include relationships from users to containers
|
||||
6. Include relationships to external systems
|
||||
7. Create a container view that shows all containers
|
||||
8. Apply autolayout for better diagram appearance
|
||||
9. Use the default theme
|
||||
|
||||
The DSL should be complete and ready to use with Structurizr Lite.
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
name: "C4 Context Diagram Template"
|
||||
description: "Template for creating C4 Context diagrams using Structurizr DSL"
|
||||
version: "1.0"
|
||||
|
||||
sections:
|
||||
- id: system-overview
|
||||
title: "System Overview"
|
||||
instruction: "Define the basic system information"
|
||||
fields:
|
||||
- id: system-name
|
||||
title: "System Name"
|
||||
type: "text"
|
||||
required: true
|
||||
placeholder: "e.g., E-commerce Platform"
|
||||
- id: system-description
|
||||
title: "System Description"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "Brief description of what the system does"
|
||||
- id: business-context
|
||||
title: "Business Context"
|
||||
type: "textarea"
|
||||
required: false
|
||||
placeholder: "Business goals, constraints, and context"
|
||||
|
||||
- id: users
|
||||
title: "Users and Actors"
|
||||
instruction: "Identify all users and external actors"
|
||||
fields:
|
||||
- id: primary-users
|
||||
title: "Primary Users"
|
||||
type: "list"
|
||||
required: true
|
||||
placeholder: "List of primary users (e.g., Customers, Administrators)"
|
||||
- id: user-goals
|
||||
title: "User Goals"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "What do users want to achieve with this system?"
|
||||
|
||||
- id: external-systems
|
||||
title: "External Systems"
|
||||
instruction: "Identify external systems and services"
|
||||
fields:
|
||||
- id: external-systems-list
|
||||
title: "External Systems"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List external systems (e.g., Payment Gateway, Email Service)"
|
||||
- id: integration-requirements
|
||||
title: "Integration Requirements"
|
||||
type: "textarea"
|
||||
required: false
|
||||
placeholder: "How does the system integrate with external systems?"
|
||||
|
||||
- id: relationships
|
||||
title: "Key Relationships"
|
||||
instruction: "Define the main interactions"
|
||||
fields:
|
||||
- id: user-interactions
|
||||
title: "User Interactions"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "How do users interact with the system?"
|
||||
- id: external-interactions
|
||||
title: "External System Interactions"
|
||||
type: "textarea"
|
||||
required: false
|
||||
placeholder: "How does the system interact with external systems?"
|
||||
|
||||
- id: llm-instructions
|
||||
title: "LLM Instructions"
|
||||
instruction: "AI processing instructions for generating the DSL"
|
||||
content: |
|
||||
Based on the provided information, generate a complete Structurizr DSL workspace that creates a C4 Context diagram. Follow these guidelines:
|
||||
|
||||
1. Use the system name and description for the workspace title
|
||||
2. Create person elements for each user type identified
|
||||
3. Create a software system element for the main system
|
||||
4. Create external software system elements for external systems
|
||||
5. Define relationships between users and the system, and between the system and external systems
|
||||
6. Include a systemContext view that shows all elements
|
||||
7. Use appropriate technology labels for relationships (e.g., "HTTPS", "API", "Database")
|
||||
8. Apply autolayout for better diagram appearance
|
||||
9. Use the default theme
|
||||
|
||||
The DSL should be complete and ready to use with Structurizr Lite.
|
||||
|
|
@ -0,0 +1,125 @@
|
|||
name: "Structurizr Workspace Template"
|
||||
description: "Template for creating complete Structurizr workspaces with all C4 model levels"
|
||||
version: "1.0"
|
||||
|
||||
sections:
|
||||
- id: workspace-overview
|
||||
title: "Workspace Overview"
|
||||
instruction: "Define the workspace metadata and scope"
|
||||
fields:
|
||||
- id: workspace-name
|
||||
title: "Workspace Name"
|
||||
type: "text"
|
||||
required: true
|
||||
placeholder: "e.g., E-commerce Platform Architecture"
|
||||
- id: workspace-description
|
||||
title: "Workspace Description"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "Brief description of the workspace and its purpose"
|
||||
- id: target-audience
|
||||
title: "Target Audience"
|
||||
type: "list"
|
||||
required: true
|
||||
placeholder: "Who will use these diagrams? (e.g., Developers, Architects, Stakeholders)"
|
||||
|
||||
- id: system-context
|
||||
title: "System Context (Level 1)"
|
||||
instruction: "Define the system context diagram elements"
|
||||
fields:
|
||||
- id: system-name
|
||||
title: "System Name"
|
||||
type: "text"
|
||||
required: true
|
||||
placeholder: "Name of the main system"
|
||||
- id: system-description
|
||||
title: "System Description"
|
||||
type: "textarea"
|
||||
required: true
|
||||
placeholder: "What does the system do?"
|
||||
- id: users
|
||||
title: "Users"
|
||||
type: "list"
|
||||
required: true
|
||||
placeholder: "List of users (e.g., Customers, Administrators, Support Staff)"
|
||||
- id: external-systems
|
||||
title: "External Systems"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List external systems (e.g., Payment Gateway, Email Service)"
|
||||
|
||||
- id: containers
|
||||
title: "Containers (Level 2)"
|
||||
instruction: "Define the container diagram elements"
|
||||
fields:
|
||||
- id: web-apps
|
||||
title: "Web Applications"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List web applications"
|
||||
- id: mobile-apps
|
||||
title: "Mobile Applications"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List mobile applications"
|
||||
- id: apis
|
||||
title: "APIs and Services"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List APIs and microservices"
|
||||
- id: databases
|
||||
title: "Databases"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List databases and storage systems"
|
||||
|
||||
- id: components
|
||||
title: "Components (Level 3)"
|
||||
instruction: "Define component diagrams for key containers"
|
||||
fields:
|
||||
- id: key-containers
|
||||
title: "Key Containers for Component Diagrams"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List containers that need component diagrams"
|
||||
- id: component-types
|
||||
title: "Component Types"
|
||||
type: "list"
|
||||
required: false
|
||||
placeholder: "List component types (e.g., Controllers, Services, Repositories)"
|
||||
|
||||
- id: styling
|
||||
title: "Styling and Theming"
|
||||
instruction: "Configure visual appearance"
|
||||
fields:
|
||||
- id: color-scheme
|
||||
title: "Color Scheme"
|
||||
type: "text"
|
||||
required: false
|
||||
placeholder: "Preferred color scheme (e.g., default, corporate, custom)"
|
||||
- id: layout-preferences
|
||||
title: "Layout Preferences"
|
||||
type: "textarea"
|
||||
required: false
|
||||
placeholder: "Any specific layout preferences or constraints"
|
||||
|
||||
- id: llm-instructions
|
||||
title: "LLM Instructions"
|
||||
instruction: "AI processing instructions for generating the DSL"
|
||||
content: |
|
||||
Based on the provided information, generate a complete Structurizr DSL workspace that includes all C4 model levels. Follow these guidelines:
|
||||
|
||||
1. Create a workspace with the specified name and description
|
||||
2. Define the model section with all elements from all levels
|
||||
3. Create appropriate views for each C4 model level:
|
||||
- System context view for Level 1
|
||||
- Container views for Level 2
|
||||
- Component views for Level 3
|
||||
4. Use consistent naming and descriptions throughout
|
||||
5. Apply appropriate technology labels for relationships
|
||||
6. Include autolayout for all views
|
||||
7. Apply the default theme or specified styling
|
||||
8. Ensure all relationships are properly defined
|
||||
9. Make the DSL complete and ready to use with Structurizr Lite
|
||||
|
||||
The DSL should be comprehensive and include all necessary elements for a complete C4 model representation.
|
||||
|
|
@ -0,0 +1,210 @@
|
|||
# Structurizr Lite Setup Guide
|
||||
|
||||
## Overview
|
||||
|
||||
This guide helps you set up Structurizr Lite for use with the BMAD C4 Architecture Expansion Pack.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Docker (recommended) OR Java 17+ (for Spring Boot)
|
||||
- Internet connection (for downloading)
|
||||
|
||||
## Installation
|
||||
|
||||
### Option 1: Docker (Recommended)
|
||||
|
||||
#### 1. Pull the Docker Image
|
||||
|
||||
```bash
|
||||
docker pull structurizr/lite
|
||||
```
|
||||
|
||||
#### 2. Create Data Directory
|
||||
|
||||
```bash
|
||||
mkdir -p ~/structurizr
|
||||
```
|
||||
|
||||
#### 3. Run Structurizr Lite
|
||||
|
||||
```bash
|
||||
docker run -it --rm -p 8080:8080 -v ~/structurizr:/usr/local/structurizr structurizr/lite
|
||||
```
|
||||
|
||||
### Option 2: Spring Boot
|
||||
|
||||
#### 1. Download the WAR File
|
||||
|
||||
```bash
|
||||
wget https://github.com/structurizr/lite/releases/latest/download/structurizr-lite.war
|
||||
```
|
||||
|
||||
#### 2. Create Data Directory
|
||||
|
||||
```bash
|
||||
mkdir -p ~/structurizr
|
||||
```
|
||||
|
||||
#### 3. Run Structurizr Lite
|
||||
|
||||
```bash
|
||||
java -jar structurizr-lite.war ~/structurizr
|
||||
```
|
||||
|
||||
### 4. Verify Installation
|
||||
|
||||
Open your browser and navigate to:
|
||||
|
||||
```
|
||||
http://localhost:8080
|
||||
```
|
||||
|
||||
You should see the Structurizr Lite interface.
|
||||
|
||||
## Configuration
|
||||
|
||||
### Default Settings
|
||||
|
||||
- **Port**: 8080
|
||||
- **Host**: localhost
|
||||
- **Data Directory**: `./data`
|
||||
|
||||
### Custom Configuration
|
||||
|
||||
You can customize Structurizr Lite by creating a `application.properties` file:
|
||||
|
||||
```properties
|
||||
# Custom port
|
||||
server.port=8080
|
||||
|
||||
# Custom data directory
|
||||
structurizr.data.directory=./data
|
||||
|
||||
# Enable CORS (if needed)
|
||||
structurizr.cors.enabled=true
|
||||
```
|
||||
|
||||
## Usage with BMAD C4 Architecture
|
||||
|
||||
### 1. Start Structurizr Lite
|
||||
|
||||
```bash
|
||||
cd structurizr-lite
|
||||
./gradlew bootRun
|
||||
```
|
||||
|
||||
### 2. Use C4 Architect Agent
|
||||
|
||||
```bash
|
||||
# In your IDE
|
||||
@c4-architect
|
||||
*create-workspace
|
||||
```
|
||||
|
||||
### 3. Import DSL Files
|
||||
|
||||
- Copy generated `.dsl` files to Structurizr Lite
|
||||
- Use the web interface to visualize diagrams
|
||||
- Export diagrams in various formats
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Port Already in Use
|
||||
|
||||
```bash
|
||||
# Find process using port 8080
|
||||
lsof -i :8080
|
||||
|
||||
# Kill the process
|
||||
kill -9 <PID>
|
||||
|
||||
# Or use a different port
|
||||
./gradlew bootRun --args='--server.port=8081'
|
||||
```
|
||||
|
||||
### Java Version Issues
|
||||
|
||||
```bash
|
||||
# Check Java version
|
||||
java -version
|
||||
|
||||
# Install Java 17+ if needed (for Spring Boot option)
|
||||
# Ubuntu/Debian
|
||||
sudo apt install openjdk-17-jdk
|
||||
|
||||
# macOS
|
||||
brew install openjdk@17
|
||||
|
||||
# Or use Docker instead (recommended)
|
||||
docker pull structurizr/lite
|
||||
```
|
||||
|
||||
### Memory Issues
|
||||
|
||||
```bash
|
||||
# Increase heap size
|
||||
export JAVA_OPTS="-Xmx2g"
|
||||
./gradlew bootRun
|
||||
```
|
||||
|
||||
## Integration with CI/CD
|
||||
|
||||
### Docker Setup
|
||||
|
||||
```dockerfile
|
||||
FROM openjdk:11-jre-slim
|
||||
|
||||
WORKDIR /app
|
||||
COPY structurizr-lite.jar .
|
||||
|
||||
EXPOSE 8080
|
||||
CMD ["java", "-jar", "structurizr-lite.jar"]
|
||||
```
|
||||
|
||||
### Docker Compose
|
||||
|
||||
```yaml
|
||||
version: '3.8'
|
||||
services:
|
||||
structurizr-lite:
|
||||
build: .
|
||||
ports:
|
||||
- '8080:8080'
|
||||
volumes:
|
||||
- ./data:/app/data
|
||||
environment:
|
||||
- JAVA_OPTS=-Xmx2g
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### 1. Data Management
|
||||
|
||||
- Regularly backup your Structurizr data directory
|
||||
- Use version control for DSL files
|
||||
- Keep workspace files organized
|
||||
|
||||
### 2. Performance
|
||||
|
||||
- Monitor memory usage
|
||||
- Use appropriate heap size
|
||||
- Consider scaling for large workspaces
|
||||
|
||||
### 3. Security
|
||||
|
||||
- Run behind a reverse proxy in production
|
||||
- Use HTTPS for external access
|
||||
- Restrict access to sensitive diagrams
|
||||
|
||||
## Support
|
||||
|
||||
For Structurizr Lite specific issues:
|
||||
|
||||
- [Structurizr Documentation](https://docs.structurizr.com/)
|
||||
- [GitHub Issues](https://github.com/structurizr/lite/issues)
|
||||
- [Structurizr Community](https://structurizr.com/help)
|
||||
|
||||
For BMAD C4 Architecture issues:
|
||||
|
||||
- [BMAD Discord](https://discord.gg/gk8jAdXWmj)
|
||||
- [BMAD GitHub Issues](https://github.com/bmadcode/bmad-method/issues)
|
||||
|
|
@ -0,0 +1,83 @@
|
|||
name: "Architecture Review Workflow"
|
||||
description: "Workflow for reviewing and improving existing architecture diagrams"
|
||||
version: "1.0.0"
|
||||
|
||||
phases:
|
||||
- id: "analysis"
|
||||
name: "Current State Analysis"
|
||||
description: "Analyze existing architecture and diagrams"
|
||||
steps:
|
||||
- agent: "c4-architect"
|
||||
task: "review-architecture"
|
||||
description: "Review existing architecture diagrams"
|
||||
prerequisites: ["existing-diagrams-available"]
|
||||
outputs: ["architecture-analysis.md", "issues-identified.md"]
|
||||
|
||||
- agent: "c4-architect"
|
||||
task: "validate-model"
|
||||
description: "Validate existing C4 model"
|
||||
prerequisites: ["analysis-complete"]
|
||||
outputs: ["validation-report.md"]
|
||||
|
||||
- id: "improvement"
|
||||
name: "Improvement and Updates"
|
||||
description: "Improve and update architecture diagrams"
|
||||
steps:
|
||||
- agent: "c4-architect"
|
||||
task: "update-diagram"
|
||||
description: "Update diagrams based on review findings"
|
||||
prerequisites: ["issues-identified"]
|
||||
outputs: ["updated-diagrams.dsl"]
|
||||
|
||||
- agent: "c4-architect"
|
||||
task: "validate-model"
|
||||
description: "Re-validate updated model"
|
||||
prerequisites: ["updates-complete"]
|
||||
outputs: ["updated-validation-report.md"]
|
||||
|
||||
- id: "documentation"
|
||||
name: "Documentation and Export"
|
||||
description: "Document changes and export updated diagrams"
|
||||
steps:
|
||||
- agent: "c4-architect"
|
||||
task: "export-diagrams"
|
||||
description: "Export updated diagrams"
|
||||
prerequisites: ["validation-passed"]
|
||||
outputs: ["updated-diagrams-export/"]
|
||||
|
||||
- agent: "c4-architect"
|
||||
task: "generate-dsl"
|
||||
description: "Generate updated workspace"
|
||||
prerequisites: ["export-complete"]
|
||||
outputs: ["updated-workspace.dsl"]
|
||||
|
||||
# Workflow conditions
|
||||
conditions:
|
||||
- name: "Issues identified"
|
||||
check: "issues-identified"
|
||||
description: "Review has identified issues to address"
|
||||
|
||||
- name: "Updates complete"
|
||||
check: "updates-complete"
|
||||
description: "All identified issues have been addressed"
|
||||
|
||||
- name: "Validation passed"
|
||||
check: "validation-passed"
|
||||
description: "Updated diagrams pass validation"
|
||||
|
||||
# Error handling
|
||||
error_handling:
|
||||
- condition: "no-issues-found"
|
||||
action: "complete-workflow"
|
||||
description: "No issues found, workflow complete"
|
||||
|
||||
- condition: "validation-failed"
|
||||
action: "return-to-improvement"
|
||||
description: "Return to improvement phase to fix validation issues"
|
||||
|
||||
# Success criteria
|
||||
success_criteria:
|
||||
- "All identified issues are addressed"
|
||||
- "Updated diagrams pass validation"
|
||||
- "Documentation reflects current state"
|
||||
- "Stakeholders approve changes"
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
name: "C4 Model Visualization Workflow"
|
||||
description: "Complete workflow for creating C4 model diagrams using Structurizr DSL"
|
||||
version: "1.0.0"
|
||||
|
||||
phases:
|
||||
- id: "planning"
|
||||
name: "Planning and Information Gathering"
|
||||
description: "Gather requirements and system information for C4 diagrams"
|
||||
steps:
|
||||
- agent: "c4-architect"
|
||||
task: "create-workspace"
|
||||
description: "Create new Structurizr workspace"
|
||||
prerequisites: []
|
||||
outputs: ["structurizr-workspace.dsl"]
|
||||
|
||||
- agent: "c4-architect"
|
||||
task: "create-context"
|
||||
description: "Create C4 Context diagram (Level 1)"
|
||||
prerequisites: ["workspace-created"]
|
||||
outputs: ["context-diagram.dsl", "context-diagram.png"]
|
||||
|
||||
- agent: "c4-architect"
|
||||
task: "create-container"
|
||||
description: "Create C4 Container diagram (Level 2)"
|
||||
prerequisites: ["context-diagram-complete"]
|
||||
outputs: ["container-diagram.dsl", "container-diagram.png"]
|
||||
|
||||
- agent: "c4-architect"
|
||||
task: "create-component"
|
||||
description: "Create C4 Component diagram (Level 3)"
|
||||
prerequisites: ["container-diagram-complete"]
|
||||
outputs: ["component-diagram.dsl", "component-diagram.png"]
|
||||
|
||||
- id: "validation"
|
||||
name: "Validation and Review"
|
||||
description: "Validate diagrams and ensure quality"
|
||||
steps:
|
||||
- agent: "c4-architect"
|
||||
task: "validate-model"
|
||||
description: "Validate C4 model consistency and completeness"
|
||||
prerequisites: ["all-diagrams-created"]
|
||||
outputs: ["validation-report.md"]
|
||||
|
||||
- agent: "c4-architect"
|
||||
task: "review-architecture"
|
||||
description: "Review architecture and suggest improvements"
|
||||
prerequisites: ["validation-complete"]
|
||||
outputs: ["review-report.md", "improvement-suggestions.md"]
|
||||
|
||||
- id: "export"
|
||||
name: "Export and Documentation"
|
||||
description: "Export diagrams and create documentation"
|
||||
steps:
|
||||
- agent: "c4-architect"
|
||||
task: "export-diagrams"
|
||||
description: "Export diagrams in various formats"
|
||||
prerequisites: ["validation-complete"]
|
||||
outputs: ["diagrams-png/", "diagrams-svg/", "diagrams-pdf/"]
|
||||
|
||||
- agent: "c4-architect"
|
||||
task: "generate-dsl"
|
||||
description: "Generate complete Structurizr DSL workspace"
|
||||
prerequisites: ["all-diagrams-validated"]
|
||||
outputs: ["complete-workspace.dsl"]
|
||||
|
||||
# Workflow conditions
|
||||
conditions:
|
||||
- name: "All diagrams created"
|
||||
check: "all-diagrams-created"
|
||||
description: "Context, container, and component diagrams are complete"
|
||||
|
||||
- name: "Validation passed"
|
||||
check: "validation-complete"
|
||||
description: "All diagrams pass validation checks"
|
||||
|
||||
- name: "Export ready"
|
||||
check: "export-ready"
|
||||
description: "All diagrams are ready for export"
|
||||
|
||||
# Error handling
|
||||
error_handling:
|
||||
- condition: "validation-failed"
|
||||
action: "return-to-creation"
|
||||
description: "Return to diagram creation phase to fix issues"
|
||||
|
||||
- condition: "export-failed"
|
||||
action: "retry-export"
|
||||
description: "Retry export with different settings"
|
||||
|
||||
# Success criteria
|
||||
success_criteria:
|
||||
- "All C4 model levels are represented"
|
||||
- "Diagrams pass validation checks"
|
||||
- "Export formats are generated successfully"
|
||||
- "Documentation is complete and accurate"
|
||||
Loading…
Reference in New Issue