Files
ISA-Frontend/.claude/skills/architecture-documentation/references/arc42.md
Lorenz Hilpert a2b29c0525 ♻️ refactor: convert architecture-documentation from command to skill
Move architecture documentation generation from a slash command to a
skill with comprehensive reference materials (C4 model, Arc42, ADR templates).
2025-12-02 12:56:56 +01:00

6.6 KiB

Arc42 Architecture Documentation Template

Overview

Arc42 is a template for architecture documentation with 12 sections covering all aspects of software architecture.

Template Structure

1. Introduction and Goals

# 1. Introduction and Goals

## 1.1 Requirements Overview
- Core business requirements driving the architecture
- Key functional requirements
- Quality goals and priorities

## 1.2 Quality Goals
| Priority | Quality Goal | Description |
|----------|-------------|-------------|
| 1 | Performance | < 200ms response time |
| 2 | Usability | Intuitive for store employees |
| 3 | Reliability | 99.9% uptime during store hours |

## 1.3 Stakeholders
| Role | Expectations |
|------|-------------|
| Store Employee | Fast, reliable daily operations |
| IT Operations | Easy deployment and monitoring |
| Development Team | Maintainable, testable code |

2. Architecture Constraints

# 2. Architecture Constraints

## 2.1 Technical Constraints
| Constraint | Background |
|------------|------------|
| Angular 20+ | Company standard frontend framework |
| TypeScript strict | Type safety requirement |
| Browser support | Chrome 90+, Edge 90+ |

## 2.2 Organizational Constraints
| Constraint | Background |
|------------|------------|
| Monorepo | Nx-based shared codebase |
| CI/CD | Azure DevOps pipelines |
| Code review | All changes require PR approval |

## 2.3 Conventions
- Conventional commits
- ESLint/Prettier formatting
- Component-driven development

3. System Scope and Context

# 3. System Scope and Context

## 3.1 Business Context
[C4 Level 1 - System Context Diagram]

| Neighbor | Description |
|----------|-------------|
| Store Employee | Primary user performing daily operations |
| Backend APIs | Provides business logic and data |
| Printer Service | Label and receipt printing |

## 3.2 Technical Context
[Deployment/Network Diagram]

| Interface | Protocol | Description |
|-----------|----------|-------------|
| REST API | HTTPS/JSON | Backend communication |
| WebSocket | WSS | Real-time updates |
| OAuth2 | HTTPS | Authentication |

4. Solution Strategy

# 4. Solution Strategy

## Key Architectural Decisions

| Decision | Rationale |
|----------|-----------|
| Angular SPA | Rich interactive UI, offline capability |
| NgRx Signal Store | Predictable state management |
| Nx Monorepo | Code sharing, consistent tooling |
| Standalone Components | Better tree-shaking, simpler imports |

## Quality Achievement Strategies

| Quality Goal | Approach |
|--------------|----------|
| Performance | Lazy loading, caching, code splitting |
| Maintainability | Domain-driven library structure |
| Testability | Component isolation, dependency injection |

5. Building Block View

# 5. Building Block View

## Level 1: Application Overview
[C4 Container Diagram]

## Level 2: Domain Decomposition
| Domain | Purpose | Libraries |
|--------|---------|-----------|
| CRM | Customer management | crm-feature-*, crm-data-access-* |
| OMS | Order management | oms-feature-*, oms-data-access-* |
| Checkout | Transactions | checkout-feature-*, checkout-data-access-* |

## Level 3: Feature Details
[C4 Component Diagrams per domain]

6. Runtime View

# 6. Runtime View

## Scenario 1: User Login
```mermaid
sequenceDiagram
    User->>App: Open application
    App->>Auth: Redirect to login
    Auth->>App: Return token
    App->>API: Fetch user profile
    API->>App: User data
    App->>User: Display dashboard

Scenario 2: Order Processing

[Sequence diagram for order flow]


### 7. Deployment View

```markdown
# 7. Deployment View

## Infrastructure
```mermaid
graph TD
    CDN[CDN] --> Browser[User Browser]
    Browser --> LB[Load Balancer]
    LB --> API[API Gateway]
    API --> Services[Backend Services]

Environments

Environment URL Purpose
Development dev.isa.local Local development
Staging staging.isa.com Integration testing
Production isa.com Live system

### 8. Cross-cutting Concepts

```markdown
# 8. Cross-cutting Concepts

## 8.1 Domain Model
[Domain entity relationships]

## 8.2 Security
- Authentication: OAuth2/OIDC
- Authorization: Role-based access control
- Data protection: HTTPS, encrypted storage

## 8.3 Error Handling
- Global error interceptor
- User-friendly error messages
- Error logging to backend

## 8.4 Logging
- @isa/core/logging library
- Structured log format
- Log levels: trace, debug, info, warn, error

9. Architecture Decisions

# 9. Architecture Decisions

See [ADR folder](../adr/) for detailed decision records.

## Key Decisions
- ADR-0001: Use Nx Monorepo
- ADR-0002: Adopt NgRx Signal Store
- ADR-0003: Migrate to Standalone Components

10. Quality Requirements

# 10. Quality Requirements

## Quality Tree

Quality ├── Performance │ ├── Response Time < 200ms │ └── Time to Interactive < 3s ├── Reliability │ ├── Uptime 99.9% │ └── Graceful degradation └── Maintainability ├── Test coverage > 80% └── Clear module boundaries


## Quality Scenarios
| Scenario | Measure | Target |
|----------|---------|--------|
| Page load | Time to interactive | < 3s |
| API call | Response time | < 200ms |
| Build | CI pipeline duration | < 10min |

11. Risks and Technical Debt

# 11. Risks and Technical Debt

## Identified Risks
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| Backend unavailable | Medium | High | Offline mode |
| Performance degradation | Low | Medium | Monitoring |

## Technical Debt
| Item | Priority | Effort |
|------|----------|--------|
| Legacy Jest tests | Medium | High |
| Any types in codebase | High | Medium |

12. Glossary

# 12. Glossary

| Term | Definition |
|------|------------|
| ADR | Architecture Decision Record |
| C4 | Context, Container, Component, Code model |
| ISA | In-Store Application |
| SPA | Single Page Application |

Best Practices

  1. Start with sections 1-4 - Goals, constraints, context, strategy
  2. Add diagrams to section 5 - Building block views
  3. Document decisions in section 9 - Link to ADRs
  4. Keep updated - Review quarterly
  5. Use templates - Consistent formatting