0x1d
0d6c62ab03
The Gin framework uses a global mode setting (gin.SetMode()) which is not thread-safe when tests run in parallel. Removing t.Parallel() from metrics tests that use gin.SetMode() prevents data races when running tests with the race detector enabled. All tests now pass with 'make test' which includes -race flag.
81 lines
4.2 KiB
Markdown
81 lines
4.2 KiB
Markdown
# 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)**: Epic-based implementation plan with timelines
|
|
- **[Playbook](playbook.md)**: Detailed implementation guide and best practices
|
|
|
|
### Architecture
|
|
- **[Architecture Overview](architecture/architecture.md)**: System architecture with diagrams
|
|
- **[Module Architecture](architecture/architecture-modules.md)**: Module system design and integration
|
|
- **[Module Requirements](architecture/module-requirements.md)**: Detailed requirements for each module
|
|
- **[Component Relationships](architecture/component-relationships.md)**: Component interactions and dependencies
|
|
- **System Specifications**
|
|
- **[System Behavior Overview](architecture/system-behavior.md)**: How the system behaves end-to-end
|
|
- **[Service Orchestration](architecture/service-orchestration.md)**: How services work together
|
|
- **[Module Integration Patterns](architecture/module-integration-patterns.md)**: How modules integrate with the platform
|
|
- **[Operational Scenarios](architecture/operational-scenarios.md)**: Common operational flows and use cases
|
|
- **[Data Flow Patterns](architecture/data-flow-patterns.md)**: How data flows through the system
|
|
|
|
### Architecture Decision Records (ADRs)
|
|
All architectural decisions are documented in [ADR records](adr/README.md), organized by implementation epic:
|
|
- **Epic 0**: Project Setup & Foundation
|
|
- **Epic 1**: Core Kernel & Infrastructure
|
|
- **Epic 2**: Authentication & Authorization
|
|
- **Epic 3**: Module Framework
|
|
- **Epic 5**: Infrastructure Adapters
|
|
- **Epic 6**: Observability & Production Readiness
|
|
- **Epic 7**: Testing, Documentation & CI/CD
|
|
|
|
### Implementation Tasks
|
|
Detailed task definitions for each epic are available in the [Stories section](stories/README.md):
|
|
- **[Epic 0: Project Setup & Foundation](stories/epic0/README.md)** - [Implementation Summary](stories/epic0/SUMMARY.md)
|
|
- **[Epic 1: Core Kernel & Infrastructure](stories/epic1/README.md)** - [Implementation Summary](stories/epic1/SUMMARY.md)
|
|
- Epic 2: Authentication & Authorization
|
|
- Epic 3: Module Framework
|
|
- Epic 4: Sample Feature Module (Blog)
|
|
- Epic 5: Infrastructure Adapters
|
|
- Epic 6: Observability & Production Readiness
|
|
- Epic 7: Testing, Documentation & CI/CD
|
|
- Epic 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 epic-based 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
|
|
- **Microservices Architecture**: Each module is an independent service from day one
|
|
- **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
|
|
|