Paul.Kim/tpl-superclaude
Template
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: 초기 파일 추가 및 기본 설정 구성

Browse Source 
- .git-commit-template.txt: 커밋 메시지 템플릿 추가
- .gitignore: OS 및 데이터베이스 관련 파일 무시 설정 추가
- .mcp.json: MCP 서버 설정 추가
- CLAUDE.md: SuperClaude 엔트리 포인트 문서 추가
- README.md: 프로젝트 템플릿 설명 추가
- .claude/COMMANDS.md: 명령어 실행 프레임워크 문서 추가
- .claude/FLAGS.md: 플래그 시스템 문서 추가
- .claude/MCP.md: MCP 서버 통합 문서 추가
- .claude/MODES.md: 운영 모드 문서 추가
- .claude/ORCHESTRATOR.md: 지능형 라우팅 시스템 문서 추가
- .claude/PERSONAS.md: 페르소나 시스템 문서 추가
- .claude/PRINCIPLES.md: 핵심 원칙 문서 추가
- .claude/RULES.md: 실행 가능한 규칙 문서 추가
- .claude/settings.json: 권한 설정 추가
- .claude/commands 디렉토리: 다양한 명령어 문서 추가
- .taskmaster/config.json: 기본 설정 파일 추가
- .taskmaster/docs 디렉토리: 문서 파일 추가
- .taskmaster/tasks/tasks.json: 기본 작업 파일 추가
This commit is contained in:
Paul.Kim
2025-07-20 22:25:33 +09:00
parent d9db49ee2e
commit c9020eb796
76 changed files with 13249 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

524
.claude/commands/design/1-system-architecture/1-create-architecture-framework.md Normal file
View File

@ -0,0 +1,524 @@
---
allowed-tools: [Read, Write, Glob, TodoWrite]
description: Creates a comprehensive system architecture framework including domain separation, layered architecture, and component responsibility definitions.
---
# Create Architecture Framework
## Context
- **User Request:** $ARGUMENTS
- **PRD Source:** Identified by `--prd` argument (PRD session name or index).
- **Source PRD:** Final PRD document from the specified PRD session directory.
- **Architecture Directory:** `.taskmaster/docs/design/architecture/`
## Goal
To transform product requirements from a completed PRD into a comprehensive system architecture framework that defines domain boundaries, architectural layers, component responsibilities, and foundational patterns necessary for scalable and maintainable software development.
## Process
1. **Identify Source PRD Session:**
- Use the `--prd` argument to locate the correct PRD session directory (e.g., `.taskmaster/docs/prd/001-enterprise-expansion/`).
- Find the final PRD document (`product-requirements-document_*.md`) within the session directory.
2. **Extract Architecture Requirements from PRD:**
- **Functional Requirements:** Core features and business capabilities
- **Non-Functional Requirements:** Performance, scalability, security, reliability
- **Technical Constraints:** Platform requirements, integration needs, compliance
- **User Experience Requirements:** Response time, availability, user load
- **Business Requirements:** Growth projections, market constraints, budget limitations
3. **Determine Architecture Session Index:**
- Scan the `.taskmaster/docs/design/architecture/` directory to find the highest existing session index.
- Assign the next sequential number for the new architecture session.
4. **Create Architecture Session Directory:**
- Create a new directory named `[index]-[prd_session_name]` inside `.taskmaster/docs/design/architecture/`.
- Example: `.taskmaster/docs/design/architecture/001-enterprise-expansion/`
5. **Initialize Architecture Session State:**
- Create a `_session-state.json` file in the new architecture session directory.
- Initialize it with architecture session details:
```json
{
"index": 1,
"name": "prd-session-name",
"type": "architecture",
"status": "initialized",
"created": "ISO datetime",
"lastUpdated": "ISO datetime",
"currentStep": "architecture_framework_creation",
"completedSteps": [],
"nextAction": "Generate comprehensive architecture framework",
"sourceType": "prd",
"sourceName": "prd-session-name",
"architectureScope": "system-wide|domain-specific|service-specific",
"architectureStyle": "layered|microservices|event-driven|hybrid",
"architectureResults": {}
}
```
6. **Perform Domain Analysis:**
- **Domain Identification:** Identify business domains and bounded contexts from PRD features
- **Domain Modeling:** Create domain models and understand domain relationships
- **Bounded Context Mapping:** Define context boundaries and integration patterns
- **Domain Events:** Identify key domain events and workflows
- **Subdomain Classification:** Classify subdomains as core, supporting, or generic
7. **Design Layered Architecture:**
- **Presentation Layer:** User interface, API endpoints, controllers
- **Application Layer:** Application services, use cases, workflow orchestration
- **Domain Layer:** Domain entities, value objects, domain services, aggregates
- **Infrastructure Layer:** Data access, external services, technical concerns
- **Cross-Cutting Concerns:** Logging, security, monitoring, configuration
8. **Define Component Responsibilities:**
- **Component Identification:** Identify major system components and modules
- **Responsibility Assignment:** Define clear responsibilities for each component
- **Interface Design:** Design component interfaces and contracts
- **Dependency Management:** Establish dependency rules and patterns
- **Component Interaction:** Define communication patterns between components
9. **Generate Architecture Framework Document:**
- Create the primary architecture document named `architecture-framework_[prd_session_name].md`.
- Structure content according to the architecture framework template.
- Include:
- **Architecture Overview:** High-level architecture vision and principles
- **Domain Architecture:** Domain boundaries and context mapping
- **Layered Architecture:** Layer definitions and responsibilities
- **Component Architecture:** Component design and interfaces
- **Architecture Patterns:** Key architectural patterns and decisions
- **Quality Attributes:** Architecture support for quality requirements
10. **Update Session State:**
- Set `status` to `framework_complete`.
- Update `architectureResults` with architecture metrics and components.
- Record completion timestamp.
11. **Notify User with Architecture Insights:**
- Inform the user that the architecture framework has been successfully generated.
- Provide the file path and key architectural highlights.
- **Suggest logical next steps based on framework outcomes:**
- "Your architecture framework is complete. Consider designing detailed components using `/design/system-architecture/2-design-components --name=[session_name]`"
- "Review the domain boundaries with your team to validate business alignment."
- "Use the layered architecture to guide development team organization and responsibilities."
## Templates & Structures
### Architecture Framework Template
```markdown
# System Architecture Framework: [PRD Session Name]
**Created:** [Date]
**Source:** PRD Session: [PRD Session Name]
**Architecture Style:** [Layered/Microservices/Event-Driven/Hybrid]
**Target Scale:** [Small/Medium/Large/Enterprise]
**Last Updated:** [Date]
---
## Architecture Overview
### Architecture Vision
- **Vision Statement:** [Clear architectural vision aligned with business goals]
- **Architecture Principles:** [Fundamental principles guiding architectural decisions]
- **Design Philosophy:** [Overall approach to system design and evolution]
- **Success Criteria:** [How architectural success will be measured]
### Architecture Drivers
- **Business Drivers:** [Key business requirements driving architecture]
- **Technical Drivers:** [Technical requirements and constraints]
- **Quality Drivers:** [Quality attributes and non-functional requirements]
- **Constraint Drivers:** [Platform, budget, time, and regulatory constraints]
### Architecture Characteristics
- **Scalability:** [Horizontal and vertical scaling approach]
- **Reliability:** [Fault tolerance and resilience patterns]
- **Performance:** [Performance targets and optimization strategies]
- **Security:** [Security architecture and protection mechanisms]
- **Maintainability:** [Code organization and maintenance strategies]
---
## Domain Architecture
### Domain Identification
#### Core Domain: [Primary Business Domain]
- **Description:** [What this domain represents in the business]
- **Key Entities:** [Main business entities and concepts]
- **Business Rules:** [Critical business rules and constraints]
- **Value Proposition:** [How this domain creates business value]
#### Supporting Domain: [Secondary Business Domain]
- **Description:** [What this domain represents in the business]
- **Key Entities:** [Main business entities and concepts]
- **Business Rules:** [Critical business rules and constraints]
- **Value Proposition:** [How this domain supports core business]
#### Generic Domain: [Utility Domain]
- **Description:** [What this domain represents in the business]
- **Key Entities:** [Main business entities and concepts]
- **Business Rules:** [Critical business rules and constraints]
- **Value Proposition:** [How this domain provides utility]
### Bounded Context Mapping
#### Context 1: [Context Name]
- **Responsibility:** [What this context is responsible for]
- **Boundaries:** [Clear boundaries and what's included/excluded]
- **Interfaces:** [How this context exposes its capabilities]
- **Dependencies:** [Other contexts this depends on]
#### Context 2: [Context Name]
- **Responsibility:** [What this context is responsible for]
- **Boundaries:** [Clear boundaries and what's included/excluded]
- **Interfaces:** [How this context exposes its capabilities]
- **Dependencies:** [Other contexts this depends on]
### Domain Events
- **Event 1:** [Event Name] - [When it occurs and what it represents]
- **Event 2:** [Event Name] - [When it occurs and what it represents]
- **Event 3:** [Event Name] - [When it occurs and what it represents]
### Context Integration Patterns
- **Shared Kernel:** [Shared models and libraries between contexts]
- **Customer-Supplier:** [Upstream/downstream relationships]
- **Conformist:** [One context conforms to another's model]
- **Anti-Corruption Layer:** [Protection against external models]
---
## Layered Architecture
### Presentation Layer
#### Responsibility
- User interface components and user interaction handling
- API endpoints and request/response handling
- Input validation and output formatting
- User authentication and session management
#### Components
- **Web Controllers:** [REST API controllers and request handlers]
- **UI Components:** [User interface components and views]
- **API Gateways:** [API gateway and routing logic]
- **Authentication Middleware:** [Authentication and authorization components]
#### Design Patterns
- **MVC Pattern:** [Model-View-Controller for web interfaces]
- **API Gateway Pattern:** [Centralized API management]
- **Frontend-Backend Separation:** [Clear separation of concerns]
### Application Layer
#### Responsibility
- Application services and use case orchestration
- Business workflow coordination
- Transaction management
- Application-specific business logic
#### Components
- **Application Services:** [Use case implementations and workflow coordination]
- **Command Handlers:** [Command pattern implementations]
- **Query Handlers:** [Query pattern implementations]
- **Workflow Orchestrators:** [Business process coordination]
#### Design Patterns
- **Command Query Responsibility Segregation (CQRS):** [Separate read/write operations]
- **Mediator Pattern:** [Request/response handling]
- **Unit of Work Pattern:** [Transaction management]
### Domain Layer
#### Responsibility
- Core business logic and domain rules
- Domain entities and value objects
- Domain services and aggregates
- Business invariants and constraints
#### Components
- **Domain Entities:** [Core business objects with identity]
- **Value Objects:** [Immutable objects representing concepts]
- **Domain Services:** [Business logic that doesn't belong to entities]
- **Aggregates:** [Consistency boundaries and transaction scopes]
- **Domain Events:** [Business events and event handlers]
#### Design Patterns
- **Domain-Driven Design (DDD):** [Domain modeling and bounded contexts]
- **Repository Pattern:** [Data access abstraction]
- **Factory Pattern:** [Complex object creation]
- **Strategy Pattern:** [Business rule variations]
### Infrastructure Layer
#### Responsibility
- Data persistence and external service integration
- Technical infrastructure and cross-cutting concerns
- Framework and technology-specific implementations
- System integration and communication
#### Components
- **Data Access Layer:** [Database access and ORM implementations]
- **External Service Clients:** [Third-party service integrations]
- **Message Brokers:** [Asynchronous communication infrastructure]
- **Configuration Management:** [Application configuration and settings]
#### Design Patterns
- **Repository Pattern:** [Data access abstraction]
- **Adapter Pattern:** [External service integration]
- **Decorator Pattern:** [Cross-cutting concerns]
---
## Component Architecture
### Component Identification
#### Component 1: [Component Name]
- **Purpose:** [What this component does and why it exists]
- **Responsibilities:** [Specific responsibilities and capabilities]
- **Interfaces:** [Public interfaces and contracts]
- **Dependencies:** [Other components this depends on]
- **Technology:** [Technology stack and frameworks]
#### Component 2: [Component Name]
- **Purpose:** [What this component does and why it exists]
- **Responsibilities:** [Specific responsibilities and capabilities]
- **Interfaces:** [Public interfaces and contracts]
- **Dependencies:** [Other components this depends on]
- **Technology:** [Technology stack and frameworks]
### Component Interaction Patterns
- **Synchronous Communication:** [REST APIs, direct method calls]
- **Asynchronous Communication:** [Message queues, event streams]
- **Data Sharing:** [Shared databases, data stores]
- **Service Discovery:** [How components find each other]
### Component Deployment
- **Deployment Units:** [How components are packaged and deployed]
- **Scalability:** [How components scale independently]
- **Fault Isolation:** [How component failures are contained]
- **Monitoring:** [How components are monitored and observed]
---
## Architecture Patterns
### Architectural Style
- **Primary Style:** [Layered/Microservices/Event-Driven/Hybrid]
- **Style Rationale:** [Why this style was chosen]
- **Style Benefits:** [Benefits this style provides]
- **Style Trade-offs:** [Trade-offs and limitations]
### Key Patterns
#### Pattern 1: [Pattern Name]
- **Problem:** [What problem this pattern solves]
- **Solution:** [How the pattern addresses the problem]
- **Implementation:** [How this pattern is implemented]
- **Benefits:** [Benefits of using this pattern]
- **Trade-offs:** [Costs and limitations]
#### Pattern 2: [Pattern Name]
- **Problem:** [What problem this pattern solves]
- **Solution:** [How the pattern addresses the problem]
- **Implementation:** [How this pattern is implemented]
- **Benefits:** [Benefits of using this pattern]
- **Trade-offs:** [Costs and limitations]
### Integration Patterns
- **API Gateway:** [Centralized API management and routing]
- **Service Mesh:** [Service-to-service communication]
- **Event Sourcing:** [Event-driven state management]
- **CQRS:** [Command Query Responsibility Segregation]
---
## Quality Attributes
### Performance Architecture
- **Response Time:** [Target response times and performance budgets]
- **Throughput:** [Expected transaction volumes and capacity]
- **Resource Usage:** [Memory, CPU, and storage considerations]
- **Caching Strategy:** [Caching layers and invalidation policies]
### Scalability Architecture
- **Horizontal Scaling:** [Scale-out capabilities and patterns]
- **Vertical Scaling:** [Scale-up capabilities and limitations]
- **Auto-scaling:** [Automatic scaling triggers and policies]
- **Load Distribution:** [Load balancing and traffic distribution]
### Reliability Architecture
- **Fault Tolerance:** [Failure handling and recovery patterns]
- **Resilience Patterns:** [Circuit breakers, retries, timeouts]
- **Backup and Recovery:** [Data backup and disaster recovery]
- **High Availability:** [Redundancy and failover mechanisms]
### Security Architecture
- **Authentication:** [User authentication and identity management]
- **Authorization:** [Access control and permission management]
- **Data Protection:** [Encryption and data privacy]
- **Security Monitoring:** [Threat detection and response]
### Maintainability Architecture
- **Code Organization:** [Module structure and dependency management]
- **Testing Strategy:** [Testing architecture and automation]
- **Documentation:** [Architecture documentation and knowledge management]
- **Evolution:** [Architecture evolution and refactoring strategies]
---
## Architecture Decisions
### Decision 1: [Decision Topic]
- **Context:** [Situation requiring a decision]
- **Decision:** [What was decided]
- **Rationale:** [Why this decision was made]
- **Consequences:** [Impact and implications]
- **Alternatives:** [Other options considered]
### Decision 2: [Decision Topic]
- **Context:** [Situation requiring a decision]
- **Decision:** [What was decided]
- **Rationale:** [Why this decision was made]
- **Consequences:** [Impact and implications]
- **Alternatives:** [Other options considered]
---
## Implementation Guidance
### Development Approach
- **Development Methodology:** [Agile, incremental, iterative approach]
- **Team Organization:** [How teams align with architecture]
- **Technology Standards:** [Coding standards and technology guidelines]
- **Quality Practices:** [Code review, testing, and quality assurance]
### Architecture Governance
- **Architecture Review:** [Architecture review process and criteria]
- **Change Management:** [How architecture changes are managed]
- **Compliance:** [Architecture compliance and enforcement]
- **Evolution:** [Architecture evolution and improvement]
### Risk Management
- **Technical Risks:** [Key technical risks and mitigation strategies]
- **Architecture Risks:** [Architecture-specific risks and responses]
- **Integration Risks:** [Component integration and system risks]
- **Performance Risks:** [Performance and scalability risks]
---
## Next Steps
### Immediate Actions
1. **Component Design:** [Design detailed component specifications]
2. **Integration Planning:** [Plan component integration and communication]
3. **Technology Selection:** [Select specific technologies and frameworks]
4. **Prototype Development:** [Develop architecture proof-of-concept]
### Architecture Validation
- **Architecture Review:** [Conduct formal architecture review]
- **Stakeholder Alignment:** [Ensure stakeholder agreement and buy-in]
- **Technical Validation:** [Validate technical feasibility and approach]
- **Risk Assessment:** [Assess and mitigate architecture risks]
### Development Preparation
- **Team Preparation:** [Prepare development teams for implementation]
- **Environment Setup:** [Set up development and testing environments]
- **Tooling Selection:** [Select development tools and frameworks]
- **Documentation:** [Create detailed implementation documentation]
---
## Appendices
### A. PRD Requirements Analysis
[Summary of PRD requirements and their architectural implications]
### B. Architecture Diagrams
[High-level architecture diagrams and component relationships]
### C. Technology Evaluation
[Technology evaluation criteria and selection rationale]
### D. Performance Modeling
[Performance projections and capacity planning]
### E. Security Assessment
[Security requirements and threat modeling]
```
### Session State Structure
```json
{
"index": 1,
"name": "prd-session-name",
"type": "architecture",
"status": "framework_complete",
"created": "ISO datetime",
"lastUpdated": "ISO datetime",
"currentStep": "framework_complete",
"completedSteps": ["architecture_framework_creation", "domain_analysis", "layer_design"],
"nextAction": "Ready for component design or integration architecture",
"sourceType": "prd",
"sourceName": "prd-session-name",
"architectureScope": "system-wide",
"architectureStyle": "layered",
"architectureResults": {
"domains": 3,
"layers": 4,
"components": 12,
"patterns": 8,
"qualityAttributes": 5,
"decisions": 6,
"createdDate": "ISO datetime"
}
}
```
## Best Practices
### ✅ DO: Requirements-Driven Architecture
- **Start with PRD requirements** and ensure architecture serves business needs
- **Prioritize quality attributes** based on business priorities and user needs
- **Consider growth and evolution** when designing architectural foundations
- **Balance flexibility with simplicity** to avoid over-engineering
**Why:** Requirements-driven architecture ensures that architectural decisions support business objectives and user value.
### ✅ DO: Domain-Driven Design
- **Identify clear domain boundaries** and model business concepts accurately
- **Use ubiquitous language** that bridges business and technical teams
- **Separate core domains** from supporting and generic domains
- **Design for domain evolution** and changing business requirements
**Why:** Domain-driven design creates architecture that reflects business reality and can evolve with business needs.
### ✅ DO: Layered Responsibility
- **Maintain clear layer separation** with well-defined responsibilities
- **Follow dependency rules** to ensure proper architectural flow
- **Avoid layer violations** and maintain architectural integrity
- **Design clean interfaces** between layers and components
**Why:** Layered responsibility creates maintainable, testable, and evolvable architecture.
### ❌ DON'T: Technology-First Architecture
- **Don't start with technology choices** before understanding requirements
- **Don't let technology constraints** drive architectural decisions
- **Don't ignore business requirements** in favor of technical preferences
- **Don't create architecture** that serves technology rather than business
**Why:** Technology-first architecture often results in solutions that don't meet business needs or user requirements.
### ❌ DON'T: Premature Optimization
- **Don't optimize for performance** before understanding actual requirements
- **Don't add complexity** for theoretical future needs
- **Don't over-engineer** solutions beyond current requirements
- **Don't ignore simplicity** in favor of sophisticated patterns
**Why:** Premature optimization creates unnecessary complexity and can hinder business agility and development velocity.
## Output
- **Format:** Comprehensive architecture framework with domain and layer design
- **Location:** `.taskmaster/docs/design/architecture/[index]-[prd_session_name]/`
- **Primary Files:**
- `architecture-framework_[prd_session_name].md` - Main architecture framework
- `_session-state.json` - Session tracking and metadata
## Example Usage
- **Create architecture framework from PRD:**
`/design/system-architecture/1-create-architecture-framework --prd="enterprise-expansion"`
- **Create by PRD index:**
`/design/system-architecture/1-create-architecture-framework --prd="1"`

785
.claude/commands/design/1-system-architecture/2-design-components.md Normal file
View File

@ -0,0 +1,785 @@
---
allowed-tools: [Read, Write, Glob, TodoWrite]
description: Designs detailed system components with specifications, interfaces, and implementation guidelines based on architecture framework.
---
# Design Components
## Context
- **User Request:** $ARGUMENTS
- **Architecture Session:** Identified by `--name` argument (architecture session name or index).
- **Source Architecture:** Architecture framework document from the specified architecture session directory.
- **Component Selection:** Optional `--components` argument to focus on specific components.
- **Design Directory:** `.taskmaster/docs/design/architecture/`
## Goal
To transform the high-level architecture framework into detailed component specifications that define interfaces, responsibilities, implementation patterns, and integration contracts necessary for development teams to build robust, maintainable software components.
## Process
1. **Identify Source Architecture Session:**
- Use the `--name` argument to locate the correct architecture session directory (e.g., `.taskmaster/docs/design/architecture/001-enterprise-expansion/`).
- Find the architecture framework document (`architecture-framework_*.md`) within the session directory.
2. **Extract Component Requirements from Architecture:**
- **Component Identification:** Components identified in the architecture framework
- **Layer Assignments:** Which architectural layer each component belongs to
- **Domain Boundaries:** Domain context and bounded context for each component
- **Quality Attributes:** Performance, security, scalability requirements per component
- **Integration Points:** How components interact with each other
3. **Process Component Selection (if specified):**
- If `--components` argument is provided, focus on specific components only
- Parse comma-separated component names or indices
- Validate that specified components exist in the architecture framework
4. **Perform Component Analysis:**
- **Responsibility Definition:** Clear definition of what each component does
- **Interface Design:** Public APIs, contracts, and communication protocols
- **Dependency Analysis:** Dependencies on other components and external systems
- **Data Flow Analysis:** How data flows through and between components
- **Error Handling:** Error handling strategies and fault tolerance patterns
5. **Design Component Specifications:**
- **Component Architecture:** Internal structure and sub-components
- **Interface Contracts:** Detailed API specifications and data models
- **Implementation Patterns:** Recommended design patterns and practices
- **Technology Guidelines:** Technology stack and framework recommendations
- **Testing Strategy:** Unit, integration, and contract testing approaches
6. **Generate Component Design Document:**
- Create the component design document named `component-design_[architecture_session_name].md`.
- Structure content according to the component design template.
- Include:
- **Component Overview:** High-level component landscape and relationships
- **Component Specifications:** Detailed specifications for each component
- **Interface Definitions:** API contracts and communication protocols
- **Implementation Guidelines:** Development patterns and best practices
- **Integration Patterns:** Component interaction and communication patterns
- **Quality Assurance:** Testing and validation approaches
7. **Create Component Interface Specifications:**
- Generate individual interface specification files for complex components
- Create API documentation and contract definitions
- Define data models and schema specifications
- Document error handling and exception patterns
8. **Update Architecture Session State:**
- Update the existing `_session-state.json` file in the architecture session directory.
- Add component design completion status and results.
- Update `completedSteps` and `nextAction` fields.
9. **Notify User with Component Insights:**
- Inform the user that the component design has been successfully generated.
- Provide file paths and key component highlights.
- **Suggest logical next steps based on component design:**
- "Your component design is complete. Consider defining integration architecture using `/design/system-architecture/3-integration-architecture --name=[session_name]`"
- "Review the component interfaces with your development teams to ensure implementation feasibility."
- "Use the component specifications to create detailed development tasks and sprint planning."
## Templates & Structures
### Component Design Template
```markdown
# Component Design: [Architecture Session Name]
**Created:** [Date]
**Source:** Architecture Framework: [Architecture Session Name]
**Component Scope:** [All Components / Specific Components]
**Target Components:** [List of components if specific scope]
**Last Updated:** [Date]
---
## Component Overview
### System Component Landscape
- **Total Components:** [Number of components in the system]
- **Layer Distribution:** [Number of components per architectural layer]
- **Domain Distribution:** [Number of components per domain]
- **Integration Complexity:** [Assessment of component integration complexity]
### Component Relationships
- **Core Components:** [Components that are central to system functionality]
- **Supporting Components:** [Components that support core functionality]
- **Infrastructure Components:** [Components that provide technical infrastructure]
- **Integration Components:** [Components that handle external integrations]
### Component Dependencies
- **High-Level Dependencies:** [Major dependency relationships between components]
- **Circular Dependencies:** [Any circular dependencies and resolution strategies]
- **External Dependencies:** [Dependencies on external systems and services]
---
## Component Specifications
### Presentation Layer Components
#### Component 1: [Component Name]
**Layer:** Presentation
**Domain:** [Domain Context]
**Responsibility:** [Primary responsibility and purpose]
##### Architecture
- **Component Type:** [Controller/Gateway/UI Component/API Handler]
- **Deployment Unit:** [How this component is deployed]
- **Scalability:** [Horizontal/Vertical scaling characteristics]
- **State Management:** [Stateless/Stateful and state handling approach]
##### Responsibilities
- **Primary Responsibility:** [Main function of this component]
- **Secondary Responsibilities:** [Additional functions and capabilities]
- **Business Rules:** [Business logic handled by this component]
- **Data Transformation:** [Data processing and transformation responsibilities]
##### Interface Definition
```typescript
// Public Interface
interface ComponentName {
// Core Methods
methodName(request: RequestType): Promise<ResponseType>;
// Event Handlers
onEvent(event: EventType): void;
// Lifecycle Methods
initialize(): Promise<void>;
shutdown(): Promise<void>;
}
// Request/Response Types
interface RequestType {
// Request structure
}
interface ResponseType {
// Response structure
}
```
##### Dependencies
- **Required Dependencies:** [Components this depends on]
- **Optional Dependencies:** [Components this can optionally use]
- **External Dependencies:** [External services and systems]
- **Infrastructure Dependencies:** [Databases, message queues, etc.]
##### Data Flow
- **Input Data:** [Data received from other components or external sources]
- **Output Data:** [Data produced and sent to other components]
- **Data Transformation:** [How data is processed and transformed]
- **Data Validation:** [Input validation and sanitization]
##### Error Handling
- **Error Types:** [Types of errors this component can encounter]
- **Error Handling Strategy:** [How errors are handled and propagated]
- **Retry Logic:** [Retry mechanisms and policies]
- **Fallback Mechanisms:** [Fallback strategies for failures]
##### Quality Attributes
- **Performance:** [Performance requirements and optimization strategies]
- **Security:** [Security requirements and implementation approach]
- **Reliability:** [Reliability requirements and fault tolerance]
- **Maintainability:** [Code organization and maintenance considerations]
##### Testing Strategy
- **Unit Testing:** [Unit testing approach and coverage]
- **Integration Testing:** [Integration testing strategy]
- **Contract Testing:** [API contract testing approach]
- **Performance Testing:** [Performance testing requirements]
##### Implementation Guidelines
- **Design Patterns:** [Recommended design patterns]
- **Technology Stack:** [Recommended technologies and frameworks]
- **Code Organization:** [Code structure and organization guidelines]
- **Configuration:** [Configuration management approach]
### Application Layer Components
#### Component 2: [Component Name]
**Layer:** Application
**Domain:** [Domain Context]
**Responsibility:** [Primary responsibility and purpose]
##### Architecture
- **Component Type:** [Application Service/Command Handler/Query Handler/Orchestrator]
- **Deployment Unit:** [How this component is deployed]
- **Scalability:** [Horizontal/Vertical scaling characteristics]
- **State Management:** [Stateless/Stateful and state handling approach]
##### Responsibilities
- **Primary Responsibility:** [Main function of this component]
- **Secondary Responsibilities:** [Additional functions and capabilities]
- **Business Rules:** [Business logic handled by this component]
- **Workflow Coordination:** [Business process coordination responsibilities]
##### Interface Definition
```typescript
// Application Service Interface
interface ApplicationService {
// Use Case Methods
executeUseCase(command: CommandType): Promise<ResultType>;
// Query Methods
handleQuery(query: QueryType): Promise<QueryResultType>;
// Workflow Methods
coordinateWorkflow(workflow: WorkflowType): Promise<void>;
}
// Command/Query Types
interface CommandType {
// Command structure
}
interface QueryType {
// Query structure
}
```
##### Dependencies
- **Domain Dependencies:** [Domain services and repositories]
- **Infrastructure Dependencies:** [Data access and external services]
- **Cross-Cutting Dependencies:** [Logging, monitoring, configuration]
##### Data Flow
- **Command Processing:** [How commands are processed]
- **Query Processing:** [How queries are handled]
- **Event Publishing:** [Events published by this component]
- **Data Persistence:** [Data storage and retrieval patterns]
##### Error Handling
- **Business Rule Violations:** [How business rule violations are handled]
- **Infrastructure Failures:** [How infrastructure failures are managed]
- **Transaction Management:** [Transaction handling and rollback strategies]
- **Compensation Patterns:** [Compensation actions for failures]
##### Quality Attributes
- **Performance:** [Performance requirements and optimization strategies]
- **Security:** [Security requirements and implementation approach]
- **Reliability:** [Reliability requirements and fault tolerance]
- **Maintainability:** [Code organization and maintenance considerations]
##### Testing Strategy
- **Unit Testing:** [Unit testing approach and coverage]
- **Integration Testing:** [Integration testing strategy]
- **Business Logic Testing:** [Business rule testing approach]
- **End-to-End Testing:** [End-to-end testing requirements]
##### Implementation Guidelines
- **Design Patterns:** [CQRS, Mediator, Unit of Work, etc.]
- **Technology Stack:** [Recommended technologies and frameworks]
- **Code Organization:** [Code structure and organization guidelines]
- **Transaction Management:** [Transaction handling guidelines]
### Domain Layer Components
#### Component 3: [Component Name]
**Layer:** Domain
**Domain:** [Domain Context]
**Responsibility:** [Primary responsibility and purpose]
##### Architecture
- **Component Type:** [Domain Service/Entity/Value Object/Aggregate]
- **Deployment Unit:** [How this component is deployed]
- **Scalability:** [Horizontal/Vertical scaling characteristics]
- **State Management:** [State handling and persistence approach]
##### Responsibilities
- **Primary Responsibility:** [Main function of this component]
- **Business Rules:** [Core business rules and invariants]
- **Domain Logic:** [Domain-specific business logic]
- **Data Integrity:** [Data consistency and validation responsibilities]
##### Interface Definition
```typescript
// Domain Service Interface
interface DomainService {
// Business Logic Methods
performBusinessOperation(params: BusinessParams): BusinessResult;
// Validation Methods
validateBusinessRules(entity: EntityType): ValidationResult;
// Calculation Methods
calculateBusinessValue(input: InputType): CalculationResult;
}
// Domain Types
interface BusinessParams {
// Business parameter structure
}
interface BusinessResult {
// Business result structure
}
```
##### Dependencies
- **Domain Dependencies:** [Other domain services and entities]
- **Infrastructure Dependencies:** [Repository interfaces]
- **External Dependencies:** [External domain services if any]
##### Data Flow
- **Entity Lifecycle:** [How entities are created, modified, and destroyed]
- **Business Events:** [Domain events generated by this component]
- **Validation Flow:** [How business rules are validated]
- **State Transitions:** [Valid state transitions and constraints]
##### Error Handling
- **Business Rule Violations:** [How business invariants are enforced]
- **Domain Exceptions:** [Domain-specific exceptions and handling]
- **Validation Failures:** [How validation failures are communicated]
- **Consistency Enforcement:** [How data consistency is maintained]
##### Quality Attributes
- **Performance:** [Performance requirements and optimization strategies]
- **Security:** [Security requirements and implementation approach]
- **Reliability:** [Reliability requirements and fault tolerance]
- **Maintainability:** [Code organization and maintenance considerations]
##### Testing Strategy
- **Unit Testing:** [Unit testing approach and coverage]
- **Domain Testing:** [Domain logic testing strategy]
- **Business Rule Testing:** [Business rule validation testing]
- **Integration Testing:** [Integration testing with repositories]
##### Implementation Guidelines
- **Design Patterns:** [Domain-Driven Design patterns]
- **Technology Stack:** [Recommended technologies and frameworks]
- **Code Organization:** [Code structure and organization guidelines]
- **Business Rule Implementation:** [How to implement business rules]
### Infrastructure Layer Components
#### Component 4: [Component Name]
**Layer:** Infrastructure
**Domain:** [Domain Context]
**Responsibility:** [Primary responsibility and purpose]
##### Architecture
- **Component Type:** [Repository/External Service Client/Message Handler/Data Access]
- **Deployment Unit:** [How this component is deployed]
- **Scalability:** [Horizontal/Vertical scaling characteristics]
- **State Management:** [Connection and resource management approach]
##### Responsibilities
- **Primary Responsibility:** [Main function of this component]
- **Data Access:** [Data persistence and retrieval responsibilities]
- **External Integration:** [External service integration responsibilities]
- **Technical Concerns:** [Cross-cutting technical concerns]
##### Interface Definition
```typescript
// Repository Interface
interface Repository<T> {
// CRUD Operations
create(entity: T): Promise<T>;
findById(id: string): Promise<T | null>;
update(entity: T): Promise<T>;
delete(id: string): Promise<void>;
// Query Operations
findBy(criteria: QueryCriteria): Promise<T[]>;
exists(criteria: QueryCriteria): Promise<boolean>;
}
// External Service Interface
interface ExternalServiceClient {
// Service Operations
callService(request: ServiceRequest): Promise<ServiceResponse>;
// Health Check
healthCheck(): Promise<HealthStatus>;
}
```
##### Dependencies
- **Database Dependencies:** [Database systems and drivers]
- **External Service Dependencies:** [Third-party services and APIs]
- **Infrastructure Dependencies:** [Message queues, caches, etc.]
- **Configuration Dependencies:** [Configuration and secrets management]
##### Data Flow
- **Data Access Patterns:** [How data is accessed and manipulated]
- **Connection Management:** [Database connection and pooling]
- **Error Handling:** [Database and service error handling]
- **Performance Optimization:** [Caching and optimization strategies]
##### Error Handling
- **Database Errors:** [Database connection and query error handling]
- **External Service Errors:** [External service failure handling]
- **Network Errors:** [Network connectivity and timeout handling]
- **Resource Errors:** [Resource exhaustion and cleanup]
##### Quality Attributes
- **Performance:** [Performance requirements and optimization strategies]
- **Security:** [Security requirements and implementation approach]
- **Reliability:** [Reliability requirements and fault tolerance]
- **Maintainability:** [Code organization and maintenance considerations]
##### Testing Strategy
- **Unit Testing:** [Unit testing approach and coverage]
- **Integration Testing:** [Integration testing strategy]
- **Database Testing:** [Database testing approach]
- **External Service Testing:** [Service integration testing]
##### Implementation Guidelines
- **Design Patterns:** [Repository, Adapter, Circuit Breaker, etc.]
- **Technology Stack:** [Recommended technologies and frameworks]
- **Code Organization:** [Code structure and organization guidelines]
- **Resource Management:** [Connection and resource management]
---
## Interface Definitions
### API Contracts
#### REST API Specification
```yaml
# OpenAPI 3.0 Specification
openapi: 3.0.0
info:
title: Component API
version: 1.0.0
description: API specification for component interfaces
paths:
/api/resource:
get:
summary: Get resource
parameters:
- name: id
in: query
required: true
schema:
type: string
responses:
'200':
description: Resource found
content:
application/json:
schema:
$ref: '#/components/schemas/Resource'
'404':
description: Resource not found
post:
summary: Create resource
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateResourceRequest'
responses:
'201':
description: Resource created
content:
application/json:
schema:
$ref: '#/components/schemas/Resource'
components:
schemas:
Resource:
type: object
properties:
id:
type: string
name:
type: string
status:
type: string
enum: [active, inactive]
CreateResourceRequest:
type: object
required:
- name
properties:
name:
type: string
description:
type: string
```
#### Message Contracts
```typescript
// Event Message Contracts
interface DomainEvent {
eventId: string;
eventType: string;
aggregateId: string;
aggregateType: string;
eventData: any;
timestamp: Date;
version: number;
}
// Command Message Contracts
interface Command {
commandId: string;
commandType: string;
payload: any;
timestamp: Date;
userId: string;
}
// Query Message Contracts
interface Query {
queryId: string;
queryType: string;
parameters: any;
timestamp: Date;
userId: string;
}
```
### Integration Protocols
#### Synchronous Communication
- **HTTP/REST:** [RESTful API patterns and conventions]
- **gRPC:** [gRPC service definitions and protocols]
- **GraphQL:** [GraphQL schema and query patterns]
#### Asynchronous Communication
- **Message Queues:** [Message queue patterns and protocols]
- **Event Streams:** [Event streaming patterns and schemas]
- **Publish-Subscribe:** [Pub/sub patterns and topic structures]
#### Data Formats
- **JSON:** [JSON schema definitions and conventions]
- **Protocol Buffers:** [Protobuf definitions and usage]
- **Avro:** [Avro schema definitions and evolution]
---
## Implementation Guidelines
### Development Patterns
#### Design Patterns by Layer
##### Presentation Layer
- **MVC Pattern:** [Model-View-Controller implementation]
- **API Gateway Pattern:** [Centralized API management]
- **Backend for Frontend (BFF):** [Client-specific backends]
##### Application Layer
- **Command Query Responsibility Segregation (CQRS):** [Separate read/write operations]
- **Mediator Pattern:** [Request/response handling]
- **Unit of Work Pattern:** [Transaction management]
##### Domain Layer
- **Domain-Driven Design (DDD):** [Domain modeling patterns]
- **Repository Pattern:** [Data access abstraction]
- **Factory Pattern:** [Complex object creation]
- **Strategy Pattern:** [Business rule variations]
##### Infrastructure Layer
- **Repository Pattern:** [Data access implementation]
- **Adapter Pattern:** [External service integration]
- **Circuit Breaker Pattern:** [Fault tolerance]
- **Decorator Pattern:** [Cross-cutting concerns]
### Technology Guidelines
#### Programming Languages
- **Primary Language:** [Main programming language and rationale]
- **Secondary Languages:** [Additional languages for specific components]
- **Language Standards:** [Coding standards and conventions]
#### Frameworks and Libraries
- **Web Framework:** [Web framework selection and configuration]
- **ORM Framework:** [Object-relational mapping framework]
- **Testing Framework:** [Testing framework and tools]
- **Logging Framework:** [Logging and monitoring framework]
#### Development Tools
- **IDE Configuration:** [Development environment setup]
- **Build Tools:** [Build automation and dependency management]
- **Code Quality Tools:** [Static analysis and quality tools]
- **Version Control:** [Version control practices and branching]
### Quality Assurance
#### Testing Strategy
- **Unit Testing:** [Component-level testing approach]
- **Integration Testing:** [Component integration testing]
- **Contract Testing:** [API contract testing]
- **End-to-End Testing:** [System-level testing]
#### Code Quality
- **Code Reviews:** [Code review process and standards]
- **Static Analysis:** [Static code analysis tools and rules]
- **Documentation:** [Code documentation standards]
- **Refactoring:** [Refactoring guidelines and practices]
#### Performance
- **Performance Testing:** [Performance testing approach]
- **Profiling:** [Performance profiling and optimization]
- **Monitoring:** [Runtime monitoring and alerting]
- **Optimization:** [Performance optimization strategies]
---
## Integration Patterns
### Component Communication
#### Synchronous Patterns
- **Direct Method Calls:** [In-process component communication]
- **HTTP APIs:** [RESTful API communication]
- **RPC Calls:** [Remote procedure call patterns]
#### Asynchronous Patterns
- **Message Queues:** [Queue-based communication]
- **Event Streams:** [Event-driven communication]
- **Publish-Subscribe:** [Pub/sub communication patterns]
#### Hybrid Patterns
- **Request-Response with Events:** [Combined synchronous/asynchronous]
- **Saga Pattern:** [Distributed transaction coordination]
- **Event Sourcing:** [Event-based state management]
### Data Consistency
#### Consistency Patterns
- **Strong Consistency:** [ACID transaction patterns]
- **Eventual Consistency:** [BASE transaction patterns]
- **Causal Consistency:** [Causal ordering patterns]
#### Conflict Resolution
- **Last Write Wins:** [Conflict resolution strategy]
- **Merge Strategies:** [Data merge and conflict resolution]
- **Compensating Actions:** [Compensation patterns for failures]
---
## Next Steps
### Component Implementation
1. **Development Planning:** [Plan component development order and dependencies]
2. **Team Assignment:** [Assign development teams to components]
3. **Interface Implementation:** [Implement component interfaces first]
4. **Component Development:** [Develop component implementations]
### Integration Planning
1. **Integration Architecture:** [Design component integration approach]
2. **Communication Protocols:** [Implement communication mechanisms]
3. **Data Flow Testing:** [Test data flow between components]
4. **End-to-End Testing:** [Test complete system integration]
### Quality Assurance
1. **Testing Implementation:** [Implement testing strategy]
2. **Code Quality Setup:** [Set up code quality tools]
3. **Performance Testing:** [Implement performance testing]
4. **Security Testing:** [Implement security testing]
---
## Appendices
### A. Component Mapping Matrix
[Matrix showing component relationships and dependencies]
### B. Interface Specifications
[Detailed interface specifications for each component]
### C. Implementation Examples
[Code examples and implementation patterns]
### D. Testing Examples
[Testing examples and test case specifications]
### E. Performance Considerations
[Performance analysis and optimization guidelines]
```
### Updated Session State Structure
```json
{
"index": 1,
"name": "architecture-session-name",
"type": "architecture",
"status": "component_design_complete",
"created": "ISO datetime",
"lastUpdated": "ISO datetime",
"currentStep": "component_design",
"completedSteps": ["architecture_framework_creation", "domain_analysis", "layer_design", "component_design"],
"nextAction": "Ready for integration architecture or summary generation",
"sourceType": "prd",
"sourceName": "prd-session-name",
"architectureScope": "system-wide",
"architectureStyle": "layered",
"architectureResults": {
"domains": 3,
"layers": 4,
"components": 12,
"componentSpecs": 12,
"interfaces": 24,
"patterns": 8,
"qualityAttributes": 5,
"decisions": 6,
"createdDate": "ISO datetime",
"componentDesignDate": "ISO datetime"
}
}
```
## Best Practices
### ✅ DO: Interface-First Design
- **Define clear interfaces** before implementing component internals
- **Use contract-first approach** for API and message design
- **Maintain interface stability** and versioning strategies
- **Document interface contracts** comprehensively
**Why:** Interface-first design enables parallel development, reduces integration issues, and improves system maintainability.
### ✅ DO: Responsibility-Driven Design
- **Assign single responsibility** to each component
- **Define clear boundaries** between component responsibilities
- **Minimize coupling** between components
- **Maximize cohesion** within components
**Why:** Responsibility-driven design creates maintainable, testable, and evolvable components.
### ✅ DO: Quality-Driven Implementation
- **Define quality requirements** for each component
- **Implement appropriate patterns** for quality attributes
- **Plan for testing** and quality assurance
- **Consider operational requirements** from the start
**Why:** Quality-driven implementation ensures that components meet production requirements and performance expectations.
### ❌ DON'T: Premature Implementation Details
- **Don't specify implementation details** too early in the design process
- **Don't couple components** to specific technologies unnecessarily
- **Don't ignore testing** and quality requirements
- **Don't forget operational concerns** like monitoring and deployment
**Why:** Premature implementation details can constrain development flexibility and complicate system evolution.
### ❌ DON'T: Monolithic Component Design
- **Don't create components** that are too large or complex
- **Don't mix concerns** within a single component
- **Don't ignore separation** of business and technical concerns
- **Don't create tight coupling** between unrelated components
**Why:** Monolithic component design reduces maintainability, testability, and team productivity.
## Output
- **Format:** Detailed component specifications with interfaces and guidelines
- **Location:** `.taskmaster/docs/design/architecture/[index]-[architecture_session_name]/`
- **Primary Files:**
- `component-design_[architecture_session_name].md` - Main component design document
- `_session-state.json` - Updated session state
## Example Usage
- **Design all components from architecture:**
`/design/system-architecture/2-design-components --name="enterprise-expansion"`
- **Design specific components:**
`/design/system-architecture/2-design-components --name="enterprise-expansion" --components="UserService,PaymentService"`
- **Design by architecture index:**
`/design/system-architecture/2-design-components --name="1"`

1192
.claude/commands/design/1-system-architecture/3-integration-architecture.md Normal file
View File

File diff suppressed because it is too large Load Diff

508
.claude/commands/design/1-system-architecture/4-generate-architecture-summary.md Normal file
View File

@ -0,0 +1,508 @@
---
allowed-tools: [Read, Write, Glob, TodoWrite]
description: Generates a comprehensive architecture summary that consolidates all system architecture components into a unified documentation package.
---
# Generate Architecture Summary
## Context
- **User Request:** $ARGUMENTS
- **Architecture Session:** Identified by `--name` argument (architecture session name or index).
- **Source Documents:** All architecture documents from the specified architecture session directory.
- **Output Format:** Optional `--format` argument (markdown, pdf, html, confluence).
- **Summary Scope:** Optional `--scope` argument to focus on specific architecture areas.
- **Design Directory:** `.taskmaster/docs/design/architecture/`
## Goal
To create a comprehensive architecture summary that consolidates the architecture framework, component design, and integration architecture into a unified, stakeholder-ready documentation package that provides clear guidance for development teams and technical decision-makers.
## Process
1. **Identify Source Architecture Session:**
- Use the `--name` argument to locate the correct architecture session directory (e.g., `.taskmaster/docs/design/architecture/001-enterprise-expansion/`).
- Find all architecture documents within the session directory:
- `architecture-framework_*.md`
- `component-design_*.md`
- `integration-architecture_*.md`
- `_session-state.json`
2. **Extract Architecture Content:**
- **Architecture Framework:** High-level architecture vision, domain boundaries, and layer design
- **Component Design:** Detailed component specifications, interfaces, and implementation guidelines
- **Integration Architecture:** Communication protocols, data flow, and service integration patterns
- **Session Metadata:** Architecture session status, metrics, and completion details
3. **Process Summary Scope (if specified):**
- If `--scope` argument is provided, focus on specific architecture areas
- Supported scopes: `executive`, `technical`, `implementation`, `operations`
- Parse and validate scope parameters
4. **Analyze Architecture Completeness:**
- **Completeness Assessment:** Verify all architecture components are defined
- **Consistency Analysis:** Check for consistency across architecture documents
- **Gap Analysis:** Identify missing components or incomplete specifications
- **Quality Assessment:** Evaluate architecture quality and adherence to best practices
5. **Generate Executive Summary:**
- **Architecture Overview:** High-level architecture vision and business alignment
- **Key Decisions:** Critical architectural decisions and their rationale
- **Risk Assessment:** Architecture risks and mitigation strategies
- **Implementation Roadmap:** Recommended implementation approach and timeline
6. **Create Technical Summary:**
- **System Architecture:** Consolidated view of system structure and components
- **Integration Patterns:** Summary of communication and integration approaches
- **Quality Attributes:** Architecture support for performance, security, and scalability
- **Technology Stack:** Recommended technologies and frameworks
7. **Generate Implementation Guide:**
- **Development Approach:** Recommended development methodology and team organization
- **Component Implementation:** Priority and sequence for component development
- **Integration Strategy:** Approach for component integration and testing
- **Quality Assurance:** Testing strategy and quality gates
8. **Create Operations Guide:**
- **Deployment Architecture:** Deployment patterns and infrastructure requirements
- **Monitoring Strategy:** Observability and monitoring approach
- **Maintenance Guidelines:** Architecture evolution and maintenance procedures
- **Troubleshooting Guide:** Common issues and resolution approaches
9. **Generate Architecture Summary Document:**
- Create the architecture summary document named `architecture-summary_[architecture_session_name].md`.
- Structure content according to the architecture summary template.
- Include:
- **Executive Summary:** High-level overview for stakeholders
- **Technical Architecture:** Detailed technical specifications
- **Implementation Guide:** Development and integration guidance
- **Operations Guide:** Deployment and maintenance procedures
- **Appendices:** Supporting documentation and references
10. **Create Supporting Documentation:**
- Generate architecture diagrams and visual representations
- Create component dependency matrices and relationship diagrams
- Generate API documentation and interface specifications
- Create implementation checklists and quality gates
11. **Process Output Format (if specified):**
- If `--format` argument is provided, generate additional formats
- Supported formats: `pdf`, `html`, `confluence`
- Maintain consistent content across all formats
12. **Update Architecture Session State:**
- Update the existing `_session-state.json` file in the architecture session directory.
- Set status to `architecture_complete` and update completion metrics.
- Add architecture summary generation status and results.
13. **Notify User with Architecture Summary:**
- Inform the user that the architecture summary has been successfully generated.
- Provide file paths and key architectural highlights.
- **Suggest logical next steps based on architecture completion:**
- "Your architecture summary is complete. Consider beginning UI/UX design using `/design/ui-ux/1-design-system --name=[session_name]`"
- "Review the architecture summary with your stakeholders for approval and feedback."
- "Use the implementation guide to create detailed development tasks and sprint planning."
## Templates & Structures
### Architecture Summary Template
```markdown
# Architecture Summary: [Architecture Session Name]
**Created:** [Date]
**Architecture Session:** [Architecture Session Name]
**Architecture Style:** [Layered/Microservices/Event-Driven/Hybrid]
**Completeness:** [Complete/Partial]
**Review Status:** [Pending/Approved/Needs Changes]
**Last Updated:** [Date]
---
## Executive Summary
### Business Context
- **Project Vision:** [High-level project vision and business objectives]
- **Business Drivers:** [Key business requirements driving this architecture]
- **Success Criteria:** [How architectural success will be measured]
- **Stakeholder Alignment:** [Key stakeholders and their concerns addressed]
### Architecture Overview
- **Architecture Style:** [Primary architectural style and rationale]
- **System Scale:** [Expected system scale and capacity requirements]
- **Key Components:** [Number and types of major system components]
- **Integration Complexity:** [Assessment of integration complexity and challenges]
### Key Architectural Decisions
#### Decision 1: [Decision Topic]
- **Decision:** [What was decided]
- **Rationale:** [Why this decision was made]
- **Impact:** [Business and technical impact]
- **Risks:** [Associated risks and mitigation strategies]
#### Decision 2: [Decision Topic]
- **Decision:** [What was decided]
- **Rationale:** [Why this decision was made]
- **Impact:** [Business and technical impact]
- **Risks:** [Associated risks and mitigation strategies]
### Risk Assessment
- **High Risk:** [Critical risks requiring immediate attention]
- **Medium Risk:** [Important risks requiring monitoring]
- **Low Risk:** [Minor risks with acceptable impact]
- **Risk Mitigation:** [Overall risk mitigation strategy]
### Implementation Roadmap
- **Phase 1:** [Initial implementation phase and timeline]
- **Phase 2:** [Subsequent phases and milestones]
- **Critical Path:** [Dependencies and critical path items]
- **Resource Requirements:** [Team size, skills, and infrastructure needs]
---
## Technical Architecture
### System Architecture Overview
- **Domain Architecture:** [Number of domains and their relationships]
- **Layer Architecture:** [Architectural layers and their responsibilities]
- **Component Architecture:** [Major components and their interactions]
- **Integration Architecture:** [Communication patterns and integration approaches]
### Domain Architecture
#### Domain 1: [Domain Name]
- **Purpose:** [What this domain represents in the business]
- **Key Components:** [Major components within this domain]
- **Boundaries:** [Clear domain boundaries and responsibilities]
- **Integration Points:** [How this domain integrates with others]
#### Domain 2: [Domain Name]
- **Purpose:** [What this domain represents in the business]
- **Key Components:** [Major components within this domain]
- **Boundaries:** [Clear domain boundaries and responsibilities]
- **Integration Points:** [How this domain integrates with others]
### Component Architecture
#### Component Summary
- **Total Components:** [Number of components in the system]
- **Layer Distribution:** [Components by architectural layer]
- **Component Types:** [Distribution of component types]
- **Integration Complexity:** [Assessment of component integration]
#### Key Components
##### Component 1: [Component Name]
- **Layer:** [Architectural layer]
- **Purpose:** [Primary responsibility]
- **Interfaces:** [Key interfaces and contracts]
- **Dependencies:** [Major dependencies]
- **Technology:** [Recommended technology stack]
##### Component 2: [Component Name]
- **Layer:** [Architectural layer]
- **Purpose:** [Primary responsibility]
- **Interfaces:** [Key interfaces and contracts]
- **Dependencies:** [Major dependencies]
- **Technology:** [Recommended technology stack]
### Integration Architecture
#### Communication Patterns
- **Synchronous:** [REST APIs, gRPC, direct calls]
- **Asynchronous:** [Message queues, event streams, pub/sub]
- **Data Integration:** [Database integration and data sharing]
- **External Integration:** [Third-party service integration]
#### Integration Protocols
- **API Standards:** [REST, GraphQL, gRPC specifications]
- **Message Formats:** [JSON, Protocol Buffers, Avro schemas]
- **Security Protocols:** [Authentication, authorization, encryption]
- **Error Handling:** [Error handling and retry patterns]
### Quality Attributes
- **Performance:** [Response time, throughput, resource usage targets]
- **Scalability:** [Horizontal and vertical scaling approaches]
- **Reliability:** [Fault tolerance and resilience patterns]
- **Security:** [Security architecture and protection mechanisms]
- **Maintainability:** [Code organization and evolution strategies]
### Technology Stack
- **Programming Languages:** [Primary and secondary languages]
- **Frameworks:** [Web, application, and infrastructure frameworks]
- **Databases:** [Database technologies and data stores]
- **Infrastructure:** [Cloud platforms, containers, orchestration]
- **Tools:** [Development, testing, and operational tools]
---
## Implementation Guide
### Development Approach
- **Methodology:** [Agile, iterative, or other development approach]
- **Team Organization:** [Team structure and responsibilities]
- **Development Standards:** [Coding standards and best practices]
- **Quality Practices:** [Code review, testing, and quality assurance]
### Component Implementation Priority
#### Phase 1: Foundation Components
- **Priority Components:** [Most critical components to implement first]
- **Implementation Order:** [Recommended sequence of implementation]
- **Dependencies:** [Key dependencies and blocking factors]
- **Timeline:** [Estimated implementation timeline]
#### Phase 2: Core Features
- **Feature Components:** [Core business functionality components]
- **Integration Points:** [Key integration points to establish]
- **Testing Strategy:** [Testing approach for this phase]
- **Risk Management:** [Phase-specific risks and mitigation]
#### Phase 3: Advanced Features
- **Enhancement Components:** [Advanced features and optimizations]
- **Performance Optimization:** [Performance tuning and optimization]
- **Monitoring Integration:** [Observability and monitoring setup]
- **Security Hardening:** [Security enhancements and hardening]
### Integration Strategy
- **Integration Testing:** [Approach for testing component integration]
- **Contract Testing:** [API contract testing and validation]
- **End-to-End Testing:** [System-level testing strategy]
- **Performance Testing:** [Performance and load testing approach]
### Quality Assurance
- **Testing Framework:** [Testing tools and frameworks]
- **Code Quality:** [Static analysis and code quality tools]
- **Security Testing:** [Security testing and vulnerability scanning]
- **Performance Monitoring:** [Performance monitoring and optimization]
### Development Environment
- **Local Development:** [Local development setup and tools]
- **CI/CD Pipeline:** [Continuous integration and deployment]
- **Environment Management:** [Development, staging, and production environments]
- **Configuration Management:** [Configuration and secrets management]
---
## Operations Guide
### Deployment Architecture
- **Deployment Strategy:** [Blue-green, canary, rolling deployments]
- **Infrastructure Requirements:** [Hardware, network, and storage requirements]
- **Scalability Configuration:** [Auto-scaling and load balancing setup]
- **Environment Management:** [Multiple environment configuration]
### Monitoring and Observability
- **Metrics Collection:** [System and application metrics]
- **Logging Strategy:** [Centralized logging and log management]
- **Distributed Tracing:** [Request tracing and performance monitoring]
- **Alerting:** [Alert rules and notification channels]
### Maintenance and Evolution
- **Architecture Evolution:** [How architecture will evolve over time]
- **Component Lifecycle:** [Component upgrade and retirement process]
- **Technology Updates:** [Framework and library update strategy]
- **Legacy Migration:** [Migration from legacy systems]
### Troubleshooting Guide
- **Common Issues:** [Frequent problems and their solutions]
- **Diagnostic Tools:** [Tools and techniques for problem diagnosis]
- **Performance Troubleshooting:** [Performance issue investigation]
- **Security Incident Response:** [Security incident handling procedures]
### Backup and Recovery
- **Backup Strategy:** [Data backup and recovery procedures]
- **Disaster Recovery:** [Disaster recovery planning and testing]
- **Business Continuity:** [Business continuity planning]
- **Recovery Testing:** [Regular recovery testing and validation]
---
## Architecture Validation
### Completeness Assessment
- **Architecture Coverage:** [Percentage of requirements covered by architecture]
- **Component Completeness:** [All required components defined]
- **Integration Completeness:** [All integrations designed and documented]
- **Quality Attribute Coverage:** [All quality requirements addressed]
### Consistency Analysis
- **Cross-Document Consistency:** [Consistency between architecture documents]
- **Interface Consistency:** [Consistent interface definitions]
- **Pattern Consistency:** [Consistent use of architectural patterns]
- **Naming Consistency:** [Consistent naming conventions]
### Gap Analysis
- **Missing Components:** [Components not yet defined or designed]
- **Incomplete Specifications:** [Specifications requiring additional detail]
- **Unaddressed Requirements:** [Requirements not covered by architecture]
- **Integration Gaps:** [Missing integration points or specifications]
### Quality Assessment
- **Architecture Quality:** [Overall architecture quality assessment]
- **Best Practices Adherence:** [Adherence to architectural best practices]
- **Pattern Usage:** [Appropriate use of architectural patterns]
- **Documentation Quality:** [Quality and completeness of documentation]
---
## Recommendations
### Immediate Actions
1. **Architecture Review:** [Conduct formal architecture review with stakeholders]
2. **Gap Resolution:** [Address identified gaps and incomplete specifications]
3. **Stakeholder Approval:** [Obtain stakeholder approval for architecture]
4. **Implementation Planning:** [Create detailed implementation plan]
### Implementation Priorities
1. **Critical Path:** [Focus on critical path components first]
2. **Risk Mitigation:** [Prioritize high-risk components for early validation]
3. **Value Delivery:** [Prioritize components that deliver early business value]
4. **Foundation First:** [Build foundational components before advanced features]
### Long-term Considerations
1. **Architecture Evolution:** [Plan for architecture evolution and growth]
2. **Technology Refresh:** [Consider technology refresh cycles]
3. **Team Growth:** [Plan for team growth and knowledge transfer]
4. **Market Changes:** [Adapt architecture to changing market conditions]
---
## Appendices
### A. Architecture Diagrams
[Comprehensive architecture diagrams and visual representations]
### B. Component Dependency Matrix
[Matrix showing component relationships and dependencies]
### C. API Specifications
[Detailed API specifications and documentation]
### D. Implementation Checklists
[Checklists for component implementation and integration]
### E. Quality Gates
[Quality gates and acceptance criteria for architecture phases]
### F. Reference Architecture
[Links to reference architectures and best practices]
### G. Glossary
[Architectural terms and definitions]
---
## Document Control
### Version History
- **Version 1.0:** [Initial architecture summary creation]
- **Version 1.1:** [First review and updates]
- **Version 1.2:** [Stakeholder feedback incorporation]
### Review and Approval
- **Technical Review:** [Technical review status and comments]
- **Stakeholder Review:** [Stakeholder review and approval status]
- **Architecture Board:** [Architecture board review and approval]
### Distribution
- **Primary Audience:** [Development teams, architects, technical leads]
- **Secondary Audience:** [Product managers, project managers, stakeholders]
- **Distribution Method:** [Document sharing and notification approach]
### Maintenance
- **Update Frequency:** [Regular update schedule and triggers]
- **Change Management:** [Process for architecture changes]
- **Version Control:** [Document version control and management]
```
### Updated Session State Structure
```json
{
"index": 1,
"name": "architecture-session-name",
"type": "architecture",
"status": "architecture_complete",
"created": "ISO datetime",
"lastUpdated": "ISO datetime",
"currentStep": "architecture_summary",
"completedSteps": ["architecture_framework_creation", "domain_analysis", "layer_design", "component_design", "integration_architecture", "architecture_summary"],
"nextAction": "Ready for UI/UX design or implementation planning",
"sourceType": "prd",
"sourceName": "prd-session-name",
"architectureScope": "system-wide",
"architectureStyle": "layered",
"architectureResults": {
"domains": 3,
"layers": 4,
"components": 12,
"componentSpecs": 12,
"interfaces": 24,
"integrationPatterns": 15,
"apiSpecs": 8,
"messageSchemas": 6,
"patterns": 8,
"qualityAttributes": 5,
"decisions": 6,
"completeness": 95,
"consistency": 92,
"quality": 88,
"createdDate": "ISO datetime",
"componentDesignDate": "ISO datetime",
"integrationArchitectureDate": "ISO datetime",
"architectureSummaryDate": "ISO datetime"
}
}
```
## Best Practices
### ✅ DO: Comprehensive Documentation
- **Include all architecture components** in the summary for complete coverage
- **Maintain consistency** across all architecture documents and references
- **Use stakeholder-appropriate language** for different audience sections
- **Provide actionable guidance** for implementation teams
**Why:** Comprehensive documentation ensures all stakeholders have the information they need to make informed decisions and take appropriate actions.
### ✅ DO: Multi-Audience Approach
- **Create executive summaries** for business stakeholders and decision-makers
- **Provide technical details** for architects and development teams
- **Include implementation guidance** for project managers and team leads
- **Offer operational procedures** for DevOps and operations teams
**Why:** Multi-audience approach ensures the architecture summary serves all stakeholders effectively and supports different decision-making needs.
### ✅ DO: Quality Assessment
- **Assess architecture completeness** and identify gaps or missing components
- **Evaluate consistency** across architecture documents and specifications
- **Validate quality attributes** and ensure requirements are met
- **Provide recommendations** for improvement and optimization
**Why:** Quality assessment ensures the architecture meets standards and provides a foundation for successful implementation.
### ❌ DON'T: Information Overload
- **Don't include excessive technical details** in executive summaries
- **Don't create monolithic documents** that are difficult to navigate
- **Don't ignore stakeholder needs** when structuring content
- **Don't forget to highlight key decisions** and their rationale
**Why:** Information overload reduces the effectiveness of the architecture summary and makes it harder for stakeholders to extract relevant information.
### ❌ DON'T: Inconsistent Information
- **Don't allow inconsistencies** between architecture documents
- **Don't use different terminologies** for the same concepts
- **Don't omit important decisions** or their rationale
- **Don't ignore gaps** or incomplete specifications
**Why:** Inconsistent information creates confusion and can lead to implementation problems and misaligned expectations.
## Output
- **Format:** Comprehensive architecture summary with multiple stakeholder perspectives
- **Location:** `.taskmaster/docs/design/architecture/[index]-[architecture_session_name]/`
- **Primary Files:**
- `architecture-summary_[architecture_session_name].md` - Main architecture summary document
- `_session-state.json` - Updated session state with completion status
- **Additional Formats:** PDF, HTML, Confluence (if requested)
## Example Usage
- **Generate complete architecture summary:**
`/design/system-architecture/4-generate-architecture-summary --name="enterprise-expansion"`
- **Generate executive summary only:**
`/design/system-architecture/4-generate-architecture-summary --name="enterprise-expansion" --scope="executive"`
- **Generate with PDF output:**
`/design/system-architecture/4-generate-architecture-summary --name="enterprise-expansion" --format="pdf"`
- **Generate by architecture index:**
`/design/system-architecture/4-generate-architecture-summary --name="1"`