Back to Bmad Method

Step 6: Project Structure & Boundaries

src/bmm-skills/3-solutioning/bmad-create-architecture/steps/step-06-structure.md

6.6.010.9 KB
Original Source

Step 6: Project Structure & Boundaries

MANDATORY EXECUTION RULES (READ FIRST):

  • πŸ›‘ NEVER generate content without user input

  • πŸ“– CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions

  • πŸ”„ CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding

  • βœ… ALWAYS treat this as collaborative discovery between architectural peers

  • πŸ“‹ YOU ARE A FACILITATOR, not a content generator

  • πŸ’¬ FOCUS on defining complete project structure and clear boundaries

  • πŸ—ΊοΈ MAP requirements/epics to architectural components

  • ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed

  • βœ… YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config {communication_language}

EXECUTION PROTOCOLS:

  • 🎯 Show your analysis before taking any action
  • πŸ—ΊοΈ Create complete project tree, not generic placeholders
  • ⚠️ Present A/P/C menu after generating project structure
  • πŸ’Ύ ONLY save when user chooses C (Continue)
  • πŸ“– Update frontmatter stepsCompleted: [1, 2, 3, 4, 5, 6] before loading next step
  • 🚫 FORBIDDEN to load next step until C is selected

COLLABORATION MENUS (A/P/C):

This step will generate content and present choices:

  • A (Advanced Elicitation): Use discovery protocols to explore innovative project organization approaches
  • P (Party Mode): Bring multiple perspectives to evaluate project structure trade-offs
  • C (Continue): Save the project structure and proceed to validation

PROTOCOL INTEGRATION:

  • When 'A' selected: Invoke the bmad-advanced-elicitation skill
  • When 'P' selected: Invoke the bmad-party-mode skill
  • PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
  • User accepts/rejects protocol changes before proceeding

CONTEXT BOUNDARIES:

  • All previous architectural decisions are complete
  • Implementation patterns and consistency rules are defined
  • Focus on physical project structure and component boundaries
  • Map requirements to specific files and directories

YOUR TASK:

Define the complete project structure and architectural boundaries based on all decisions made, creating a concrete implementation guide for AI agents.

PROJECT STRUCTURE SEQUENCE:

1. Analyze Requirements Mapping

Map project requirements to architectural components:

From Epics (if available): "Epic: {{epic_name}} β†’ Lives in {{module/directory/service}}"

  • User stories within the epic
  • Cross-epic dependencies
  • Shared components needed

From FR Categories (if no epics): "FR Category: {{fr_category_name}} β†’ Lives in {{module/directory/service}}"

  • Related functional requirements
  • Shared functionality across categories
  • Integration points between categories

2. Define Project Directory Structure

Based on technology stack and patterns, create the complete project structure:

Root Configuration Files:

  • Package management files (package.json, requirements.txt, etc.)
  • Build and development configuration
  • Environment configuration files
  • CI/CD pipeline files
  • Documentation files

Source Code Organization:

  • Application entry points
  • Core application structure
  • Feature/module organization
  • Shared utilities and libraries
  • Configuration and environment files

Test Organization:

  • Unit test locations and structure
  • Integration test organization
  • End-to-end test structure
  • Test utilities and fixtures

Build and Distribution:

  • Build output directories
  • Distribution files
  • Static assets
  • Documentation build

3. Define Integration Boundaries

Map how components communicate and where boundaries exist:

API Boundaries:

  • External API endpoints
  • Internal service boundaries
  • Authentication and authorization boundaries
  • Data access layer boundaries

Component Boundaries:

  • Frontend component communication patterns
  • State management boundaries
  • Service communication patterns
  • Event-driven integration points

Data Boundaries:

  • Database schema boundaries
  • Data access patterns
  • Caching boundaries
  • External data integration points

4. Create Complete Project Tree

Generate a comprehensive directory structure showing all files and directories:

Technology-Specific Structure Examples:

Next.js Full-Stack:

project-name/
β”œβ”€β”€ README.md
β”œβ”€β”€ package.json
β”œβ”€β”€ next.config.js
β”œβ”€β”€ tailwind.config.js
β”œβ”€β”€ tsconfig.json
β”œβ”€β”€ .env.local
β”œβ”€β”€ .env.example
β”œβ”€β”€ .gitignore
β”œβ”€β”€ .github/
β”‚   └── workflows/
β”‚       └── ci.yml
β”œβ”€β”€ src/
β”‚   β”œβ”€β”€ app/
β”‚   β”‚   β”œβ”€β”€ globals.css
β”‚   β”‚   β”œβ”€β”€ layout.tsx
β”‚   β”‚   └── page.tsx
β”‚   β”œβ”€β”€ components/
β”‚   β”‚   β”œβ”€β”€ ui/
β”‚   β”‚   β”œβ”€β”€ forms/
β”‚   β”‚   └── features/
β”‚   β”œβ”€β”€ lib/
β”‚   β”‚   β”œβ”€β”€ db.ts
β”‚   β”‚   β”œβ”€β”€ auth.ts
β”‚   β”‚   └── utils.ts
β”‚   β”œβ”€β”€ types/
β”‚   └── middleware.ts
β”œβ”€β”€ prisma/
β”‚   β”œβ”€β”€ schema.prisma
β”‚   └── migrations/
β”œβ”€β”€ tests/
β”‚   β”œβ”€β”€ __mocks__/
β”‚   β”œβ”€β”€ components/
β”‚   └── e2e/
└── public/
    └── assets/

API Backend (NestJS):

project-name/
β”œβ”€β”€ package.json
β”œβ”€β”€ nest-cli.json
β”œβ”€β”€ tsconfig.json
β”œβ”€β”€ .env
β”œβ”€β”€ .env.example
β”œβ”€β”€ .gitignore
β”œβ”€β”€ README.md
β”œβ”€β”€ src/
β”‚   β”œβ”€β”€ main.ts
β”‚   β”œβ”€β”€ app.module.ts
β”‚   β”œβ”€β”€ config/
β”‚   β”œβ”€β”€ modules/
β”‚   β”‚   β”œβ”€β”€ auth/
β”‚   β”‚   β”œβ”€β”€ users/
β”‚   β”‚   └── common/
β”‚   β”œβ”€β”€ services/
β”‚   β”œβ”€β”€ repositories/
β”‚   β”œβ”€β”€ decorators/
β”‚   β”œβ”€β”€ pipes/
β”‚   β”œβ”€β”€ guards/
β”‚   └── interceptors/
β”œβ”€β”€ test/
β”‚   β”œβ”€β”€ unit/
β”‚   β”œβ”€β”€ integration/
β”‚   └── e2e/
β”œβ”€β”€ prisma/
β”‚   β”œβ”€β”€ schema.prisma
β”‚   └── migrations/
└── docker-compose.yml

5. Map Requirements to Structure

Create explicit mapping from project requirements to specific files/directories:

Epic/Feature Mapping: "Epic: User Management

  • Components: src/components/features/users/
  • Services: src/services/users/
  • API Routes: src/app/api/users/
  • Database: prisma/migrations/users
  • Tests: tests/features/users/"

Cross-Cutting Concerns: "Authentication System

  • Components: src/components/auth/
  • Services: src/services/auth/
  • Middleware: src/middleware/auth.ts
  • Guards: src/guards/auth.guard.ts
  • Tests: tests/auth/"

6. Generate Structure Content

Prepare the content to append to the document:

Content Structure:

markdown
## Project Structure & Boundaries

### Complete Project Directory Structure

{{complete_project_tree_with_all_files_and_directories}}


### Architectural Boundaries

**API Boundaries:**
{{api_boundary_definitions_and_endpoints}}

**Component Boundaries:**
{{component_communication_patterns_and_boundaries}}

**Service Boundaries:**
{{service_integration_patterns_and_boundaries}}

**Data Boundaries:**
{{data_access_patterns_and_boundaries}}

### Requirements to Structure Mapping

**Feature/Epic Mapping:**
{{mapping_of_epics_or_features_to_specific_directories}}

**Cross-Cutting Concerns:**
{{mapping_of_shared_functionality_to_locations}}

### Integration Points

**Internal Communication:**
{{how_components_within_the_project_communicate}}

**External Integrations:**
{{third_party_service_integration_points}}

**Data Flow:**
{{how_data_flows_through_the_architecture}}

### File Organization Patterns

**Configuration Files:**
{{where_and_how_config_files_are_organized}}

**Source Organization:**
{{how_source_code_is_structured_and_organized}}

**Test Organization:**
{{how_tests_are_structured_and_organized}}

**Asset Organization:**
{{how_static_and_dynamic_assets_are_organized}}

### Development Workflow Integration

**Development Server Structure:**
{{how_the_project_is organized_for_development}}

**Build Process Structure:**
{{how_the_build_process_uses_the_project_structure}}

**Deployment Structure:**
{{how_the_project_structure_supports_deployment}}

7. Present Content and Menu

Show the generated project structure content and present choices:

"I've created a complete project structure based on all our architectural decisions.

Here's what I'll add to the document:

[Show the complete markdown content from step 6]

What would you like to do? [A] Advanced Elicitation - Explore innovative project organization approaches [P] Party Mode - Review structure from different development perspectives [C] Continue - Save this structure and move to architecture validation"

8. Handle Menu Selection

If 'A' (Advanced Elicitation):

  • Invoke the bmad-advanced-elicitation skill with current project structure
  • Process enhanced organizational insights that come back
  • Ask user: "Accept these changes to the project structure? (y/n)"
  • If yes: Update content, then return to A/P/C menu
  • If no: Keep original content, then return to A/P/C menu

If 'P' (Party Mode):

  • Invoke the bmad-party-mode skill with project structure context
  • Process collaborative insights about organization trade-offs
  • Ask user: "Accept these changes to the project structure? (y/n)"
  • If yes: Update content, then return to A/P/C menu
  • If no: Keep original content, then return to A/P/C menu

If 'C' (Continue):

  • Append the final content to {planning_artifacts}/architecture.md
  • Update frontmatter: stepsCompleted: [1, 2, 3, 4, 5, 6]
  • Load ./step-07-validation.md

APPEND TO DOCUMENT:

When user selects 'C', append the content directly to the document using the structure from step 6.

SUCCESS METRICS:

βœ… Complete project tree defined with all files and directories βœ… All architectural boundaries clearly documented βœ… Requirements/epics mapped to specific locations βœ… Integration points and communication patterns defined βœ… Project structure aligned with chosen technology stack βœ… A/P/C menu presented and handled correctly βœ… Content properly appended to document when C selected

FAILURE MODES:

❌ Creating generic placeholder structure instead of specific, complete tree ❌ Not mapping requirements to specific files and directories ❌ Missing important integration boundaries ❌ Not considering the chosen technology stack in structure design ❌ Not defining how components communicate across boundaries ❌ Not presenting A/P/C menu after content generation

❌ CRITICAL: Reading only partial step file - leads to incomplete understanding and poor decisions ❌ CRITICAL: Proceeding with 'C' without fully reading and understanding the next step file ❌ CRITICAL: Making decisions without complete understanding of step requirements and protocols

NEXT STEP:

After user selects 'C' and content is saved to document, load ./step-07-validation.md to validate architectural coherence and completeness.

Remember: Do NOT proceed to step-07 until user explicitly selects 'C' from the A/P/C menu and content is saved!