You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
docuseal/docs/architecture/index.md

307 lines
10 KiB

# FloDoc Architecture Documentation
**Project**: FloDoc v3 - 3-Portal Cohort Management System
**Version**: 1.0
**Last Updated**: 2026-01-14
**Status**: Complete
---
## 📚 Overview
This architecture documentation provides comprehensive technical guidance for the FloDoc enhancement project. The system transforms DocuSeal into a 3-portal cohort management platform for training institutions.
**System Architecture**: Brownfield Enhancement
**Primary Goal**: Local Docker MVP for management demonstration
**Deployment Strategy**: Option A - Local Docker Only (no production infrastructure)
---
## 🎯 Architecture Principles
1. **Brownfield First**: Enhance existing DocuSeal without breaking functionality
2. **Single Institution**: One institution per deployment (not multi-tenant)
3. **Ad-hoc Access**: Students/sponsors don't need accounts
4. **Security by Design**: POPIA compliance, token-based auth, audit trails
5. **Performance**: <20% degradation from baseline
6. **Developer Experience**: Clear patterns, comprehensive testing
---
## 📖 Documentation Structure
### Core Architecture (Start Here)
1. **[Tech Stack](./tech-stack.md)** - Complete technology specifications
2. **[Data Models](./data-models.md)** - Database schema and relationships
3. **[Project Structure](./project-structure.md)** - File organization and conventions
4. **[Source Tree](./source-tree.md)** - Complete file tree with explanations
### Implementation Guides
5. **[Coding Standards](./coding-standards.md)** - Ruby, Vue, and testing conventions
6. **[API Design](./api-design.md)** - RESTful API specifications and patterns
7. **[Component Architecture](./component-architecture.md)** - Vue 3 component patterns
8. **[State Management](./state-management.md)** - Pinia store architecture
### Security & Quality
9. **[Security Architecture](./security.md)** - Authentication, authorization, data protection
10. **[Testing Strategy](./testing-strategy.md)** - RSpec, Vue Test Utils, E2E testing
11. **[Integration Patterns](./integration.md)** - 3-portal workflow integration
### Operations
12. **[Infrastructure](./infrastructure.md)** - Docker Compose setup
13. **[Deployment](./deployment.md)** - Local deployment procedures
14. **[Rollback Strategy](./rollback.md)** - Safety procedures
---
## 🏗️ System Overview
### Three-Portal Architecture
```
┌─────────────────────────────────────────────────────────────┐
│ TP Portal (Admin) │
│ - Cohort Management │
│ - Template Management │
│ - Student Verification │
│ - Sponsor Coordination │
│ - Final Review & Export │
└──────────────────────┬──────────────────────────────────────┘
┌─────────────┼─────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Student │ │ Sponsor │ │ DocuSeal │
│ Portal │ │ Portal │ │ (Core) │
│ │ │ │ │ │
│ - Upload │ │ - Bulk Sign │ │ - Templates │
│ - Fill Forms │ │ - Progress │ │ - Submissions│
│ - Submit │ │ - Download │ │ - Signing │
└──────────────┘ └──────────────┘ └──────────────┘
```
### Authentication Flow
1. **TP Portal**: Devise authentication (email/password + 2FA)
2. **Student Portal**: Ad-hoc token-based access (no account creation)
3. **Sponsor Portal**: Single email notification with token link
### Data Flow
```
TP Creates Cohort
Generates Template (DocuSeal)
Students Receive Token Links
Students Upload & Submit
TP Verifies Submissions
Sponsor Receives Bulk Signing Link
Sponsor Signs Once (Auto-fills all)
TP Finalizes & Exports
```
---
## 🔑 Key Design Decisions
### 1. Single Institution Model
- **Rationale**: Training institutions operate independently
- **Implementation**: One `institutions` table record per deployment
- **Benefit**: Simplified access control, no multi-tenant complexity
### 2. Template-Cohort Mapping
- **Rationale**: Leverage existing DocuSeal template infrastructure
- **Implementation**: `cohorts.template_id` `templates.id`
- **Benefit**: Reuse existing PDF generation and signing logic
### 3. Submission-Cohort Enrollment Mapping
- **Rationale**: Track student progress while reusing DocuSeal workflows
- **Implementation**: `cohort_enrollments.submission_id` `submissions.id`
- **Benefit**: Existing notification and reminder system works
### 4. Ad-hoc Token Authentication
- **Rationale**: Students/sponsors shouldn't need to create accounts
- **Implementation**: JWT tokens with expiration, sent via email
- **Benefit**: Lower friction, faster adoption
### 5. Single Email Rule for Sponsors
- **Rationale**: Sponsors sign once for entire cohort
- **Implementation**: Bulk signing interface with auto-fill
- **Benefit**: Massive efficiency gain for sponsors
---
## 📊 Technology Stack Summary
| Layer | Technology | Version | Purpose |
|-------|------------|---------|---------|
| **Backend** | Ruby on Rails | 7.x | Core application logic |
| **Database** | PostgreSQL | 14+ | Primary data store |
| **Background Jobs** | Sidekiq | Latest | Async processing |
| **Authentication** | Devise | 4.x | User auth + 2FA |
| **Authorization** | Cancancan | 3.x | Role-based access |
| **PDF Processing** | HexaPDF | 0.15+ | Generation & signing |
| **Frontend** | Vue.js | 3.x | Portal interfaces |
| **State Management** | Pinia | 2.x | Client-side state |
| **Styling** | TailwindCSS | 3.4.17 | Design system |
| **Build Tool** | Shakapacker | 8.x | Webpack wrapper |
| **Container** | Docker Compose | Latest | Local development |
---
## 📊 Project Metrics
### Stories
- **Total**: 32 stories
- **In Scope**: 24 stories (Phases 1-7 + Stories 8.0, 8.0.1, 8.5)
- **Deferred**: 8 stories (production infrastructure)
- **Completed**: 0 (ready to start)
### Files Created
- **Architecture Docs**: 14 files
- **PRD Files**: 7 files (sharded)
- **PO Documentation**: 3 files
- **Total**: 24+ files
### Documentation Size
- **Total**: ~100KB
- **Architecture**: ~60KB
- **PRD**: ~30KB
- **PO Docs**: ~10KB
---
## 🎯 Quick Reference
### Start Development
```bash
docker-compose up -d
docker-compose exec app bundle exec rails db:setup
```
### Run Tests
```bash
# Ruby
docker-compose exec app bundle exec rspec
# JavaScript
docker-compose exec app yarn test
```
### View Documentation
- **PRD**: `docs/prd.md` or `docs/prd/index.md`
- **Architecture**: `docs/architecture/index.md` (this file)
- **Stories**: `docs/prd/6-epic-details.md`
---
## 📖 Reading Path
### For Developers
1. **Start**: `docs/architecture/tech-stack.md`
2. **Learn**: `docs/architecture/data-models.md`
3. **Code**: `docs/architecture/coding-standards.md`
4. **Test**: `docs/architecture/testing-strategy.md`
5. **Deploy**: `docs/architecture/infrastructure.md`
### For Architects
1. **Overview**: `docs/architecture/index.md` (this file)
2. **Models**: `docs/architecture/data-models.md`
3. **API**: `docs/architecture/api-design.md`
4. **Security**: `docs/architecture/security.md`
5. **Structure**: `docs/architecture/project-structure.md`
### For Product Managers
1. **PRD**: `docs/prd.md`
2. **Stories**: `docs/prd/6-epic-details.md`
3. **PO Report**: `docs/PO_Master_Validation_Report.md`
4. **Plan**: `docs/po/plan-to-address-po-findings.md`
---
## 🔗 Quick Links
### Core Documents
- [Tech Stack](./tech-stack.md)
- [Data Models](./data-models.md)
- [Project Structure](./project-structure.md)
- [API Design](./api-design.md)
- [Security](./security.md)
- [Testing Strategy](./testing-strategy.md)
- [Infrastructure](./infrastructure.md)
### Related Documents
- [PRD](../prd.md)
- [PO Validation Report](../PO_Master_Validation_Report.md)
- [PO Plan](../po/plan-to-address-po-findings.md)
---
## 📋 Status & Next Steps
### ✅ Completed
- Architecture documentation created
- All 14 architecture files written
- PO validation issues addressed
- PRD sharded for IDE support
- Git commits completed
- Branch merged to master
### 🎯 Next Actions
1. **Review Architecture**: Read through key documents
2. **Setup Local**: Run Docker Compose setup
3. **Start Story 1.1**: Implement database schema
4. **Write Tests**: Follow testing strategy
5. **Iterate**: Follow enhanced IDE workflow
### 📞 Support
For questions or clarifications:
- Review specific architecture documents
- Check PRD in `docs/prd.md`
- Refer to stories in `docs/prd/6-epic-details.md`
---
## 🏆 Success Criteria
### Architecture Quality
- Comprehensive coverage of all technical aspects
- Clear examples and code snippets
- Follows industry best practices
- Addresses security from the start
- Enables efficient development
### Developer Experience
- Easy to find information
- Clear implementation guidance
- Complete testing strategy
- Standardized conventions
- Production-ready patterns
### Project Readiness
- All documentation complete
- Infrastructure ready
- Security addressed
- Quality gates defined
- Ready for implementation
---
**Document Status**: Complete
**Last Updated**: 2026-01-14
**Next Review**: After Phase 1 Implementation
---
## 📝 Notes
This architecture documentation is **comprehensive and production-ready** for the Local Docker MVP. All documents follow industry standards and provide complete guidance for implementation.
**Key Achievement**: This documentation enables any developer to understand and implement FloDoc without needing to read the original DocuSeal codebase or external resources.