docs: add mkdocs, update links, add architecture documentation
This commit is contained in:
74
docs/content/index.md
Normal file
74
docs/content/index.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# Go Platform Documentation
|
||||
|
||||
Welcome to the Go Platform documentation! This is a plugin-friendly SaaS/Enterprise platform built with Go.
|
||||
|
||||
## What is Go Platform?
|
||||
|
||||
Go Platform is a modular, extensible platform designed to support multiple business domains through a plugin architecture. It provides:
|
||||
|
||||
- **Core Kernel**: Foundation services including authentication, authorization, configuration, logging, and observability
|
||||
- **Module Framework**: Plugin system for extending functionality
|
||||
- **Infrastructure Adapters**: Support for databases, caching, event buses, and job scheduling
|
||||
- **Security-by-Design**: Built-in JWT authentication, RBAC/ABAC authorization, and audit logging
|
||||
- **Observability**: OpenTelemetry integration for tracing, metrics, and logging
|
||||
|
||||
## Documentation Structure
|
||||
|
||||
### 📋 Overview
|
||||
- **[Requirements](requirements.md)**: High-level architectural principles and requirements
|
||||
- **[Implementation Plan](plan.md)**: Phased implementation plan with timelines
|
||||
- **[Playbook](playbook.md)**: Detailed implementation guide and best practices
|
||||
|
||||
### 🏛️ Architecture
|
||||
- **[Architecture Overview](architecture.md)**: System architecture with diagrams
|
||||
- **[Module Architecture](architecture-modules.md)**: Module system design and integration
|
||||
- **[Module Requirements](module-requirements.md)**: Detailed requirements for each module
|
||||
- **[Component Relationships](component-relationships.md)**: Component interactions and dependencies
|
||||
|
||||
### 🏗️ Architecture Decision Records (ADRs)
|
||||
All architectural decisions are documented in [ADR records](adr/README.md), organized by implementation phase:
|
||||
- **Phase 0**: Project Setup & Foundation
|
||||
- **Phase 1**: Core Kernel & Infrastructure
|
||||
- **Phase 2**: Authentication & Authorization
|
||||
- **Phase 3**: Module Framework
|
||||
- **Phase 5**: Infrastructure Adapters
|
||||
- **Phase 6**: Observability & Production Readiness
|
||||
- **Phase 7**: Testing, Documentation & CI/CD
|
||||
|
||||
### 📝 Implementation Tasks
|
||||
Detailed task definitions for each phase are available in the [Stories section](stories/README.md):
|
||||
- Phase 0: Project Setup & Foundation
|
||||
- Phase 1: Core Kernel & Infrastructure
|
||||
- Phase 2: Authentication & Authorization
|
||||
- Phase 3: Module Framework
|
||||
- Phase 4: Sample Feature Module (Blog)
|
||||
- Phase 5: Infrastructure Adapters
|
||||
- Phase 6: Observability & Production Readiness
|
||||
- Phase 7: Testing, Documentation & CI/CD
|
||||
- Phase 8: Advanced Features & Polish (Optional)
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. Review the [Requirements](requirements.md) to understand the platform goals
|
||||
2. Check the [Implementation Plan](plan.md) for the phased approach
|
||||
3. Follow the [Playbook](playbook.md) for implementation details
|
||||
4. Refer to [ADRs](adr/README.md) when making architectural decisions
|
||||
5. Use the [Task Stories](stories/README.md) as a checklist for implementation
|
||||
|
||||
## Key Principles
|
||||
|
||||
- **Clean/Hexagonal Architecture**: Clear separation between core and plugins
|
||||
- **Modular Monolith**: Start simple, evolve to microservices if needed
|
||||
- **Plugin-First Design**: Extensible architecture supporting static and dynamic modules
|
||||
- **Security-by-Design**: Built-in authentication, authorization, and audit capabilities
|
||||
- **Observability**: Comprehensive logging, metrics, and tracing
|
||||
- **API-First**: OpenAPI/GraphQL schema generation
|
||||
|
||||
## Contributing
|
||||
|
||||
When contributing to the platform:
|
||||
1. Review relevant ADRs before making architectural decisions
|
||||
2. Follow the task structure defined in the Stories
|
||||
3. Update documentation as you implement features
|
||||
4. Ensure all tests pass before submitting changes
|
||||
|
||||
Reference in New Issue
Block a user