docs: Align documentation with true microservices architecture

Transform all documentation from modular monolith to true microservices
architecture where core services are independently deployable.

Key Changes:
- Core Kernel: Infrastructure only (no business logic)
- Core Services: Auth, Identity, Authz, Audit as separate microservices
  - Each service has own entry point (cmd/{service}/)
  - Each service has own gRPC server and database schema
  - Services register with Consul for service discovery
- API Gateway: Moved from Epic 8 to Epic 1 as core infrastructure
  - Single entry point for all external traffic
  - Handles routing, JWT validation, rate limiting, CORS
- Service Discovery: Consul as primary mechanism (ADR-0033)
- Database Pattern: Per-service connections with schema isolation

Documentation Updates:
- Updated all 9 architecture documents
- Updated 4 ADRs and created 2 new ADRs (API Gateway, Service Discovery)
- Rewrote Epic 1: Core Kernel & Infrastructure (infrastructure only)
- Rewrote Epic 2: Core Services (Auth, Identity, Authz, Audit as services)
- Updated Epic 3-8 stories for service architecture
- Updated plan.md, playbook.md, requirements.md, index.md
- Updated all epic READMEs and story files

New ADRs:
- ADR-0032: API Gateway Strategy
- ADR-0033: Service Discovery Implementation (Consul)

New Stories:
- Epic 1.7: Service Client Interfaces
- Epic 1.8: API Gateway Implementation
This commit is contained in:
2025-11-06 08:47:27 +01:00
parent cab7cadf9e
commit 38a251968c
47 changed files with 3190 additions and 1613 deletions

View File

@@ -1,83 +1,97 @@
# Story 3.3: Module Loader and Initialization
# Story 3.3: Service Loader and Initialization
## Metadata
- **Story ID**: 3.3
- **Title**: Module Loader and Initialization
- **Epic**: 3 - Module Framework
- **Title**: Service Loader and Initialization
- **Epic**: 3 - Module Framework (Feature Services)
- **Status**: Pending
- **Priority**: High
- **Estimated Time**: 6-8 hours
- **Dependencies**: 3.1, 1.2
- **Dependencies**: 3.1, 1.2, 1.7
## Goal
Implement module loading (static and dynamic) with dependency resolution and automatic initialization.
Implement service initialization helpers for feature services with dependency resolution, Consul registration, and automatic migration execution. Each service initializes itself in its own entry point.
## Description
This story implements the complete module loading system that discovers modules, resolves dependencies, initializes them in the correct order, and runs their migrations. It supports both static registration (preferred) and dynamic plugin loading.
This story implements service initialization helpers that feature services use in their entry points (`cmd/{service}/main.go`). Services initialize themselves, resolve dependencies (other services), register with Consul, run migrations, and start their gRPC servers. The loader provides helpers for common service initialization patterns.
## Deliverables
### 1. Module Loader (`internal/pluginloader/loader.go`)
- Support static registration (preferred method)
- Optional: Go plugin loading (`.so` files)
- Module discovery from `modules/*/module.yaml`
- Loader interface for extensibility
### 1. Service Initialization Helpers (`internal/service/init.go`)
- `InitializeService(cfg, module IModule)` function
- Bootstrap core kernel services
- Initialize service-specific components
- Register with Consul service registry
- Run database migrations (per-service schema)
- Start gRPC server
- Handle graceful shutdown
### 2. Static Loader (`internal/pluginloader/static_loader.go`)
- Import modules via side-effect imports
- Collect all registered modules
- Module discovery and registration
### 2. Service Dependency Resolution (`internal/service/deps.go`)
- Resolve service dependencies (check other services are available via Consul)
- Wait for dependent services to be healthy
- Service discovery integration
- Dependency validation
### 3. Optional Plugin Loader (`internal/pluginloader/plugin_loader.go`)
- Scan `./plugins/*.so` files
- Load via `plugin.Open()`
- Extract and validate module symbols
- Version compatibility checking
### 3. Service Bootstrap Pattern (`internal/service/bootstrap.go`)
- Common bootstrap pattern for feature services
- FX lifecycle integration
- Service registration helpers
- Health check setup
- Migration runner (per-service)
### 4. Module Initializer (`internal/module/initializer.go`)
- Collect all registered modules
- Resolve dependency order (topological sort)
- Initialize each module's `Init()` fx.Option
- Merge all options into main fx container
- Run migrations in dependency order
- Handle errors gracefully
### 4. Service Template/Scaffolding
- Service template generator
- Standard service structure
- Example service entry point
### 5. FX Lifecycle Integration
- Call `OnStart()` during app startup
- Call `OnStop()` during graceful shutdown
- Proper error handling
**Note:** Each feature service has its own `cmd/{service}/main.go` that uses these helpers to initialize itself.
## Implementation Steps
1. **Create Module Loader**
- Create `internal/pluginloader/loader.go`
- Define loader interface
1. **Create Service Initialization Helpers**
- Create `internal/service/init.go`
- Implement service bootstrap pattern
- Integrate with Consul service registry
2. **Implement Static Loader**
- Create `internal/pluginloader/static_loader.go`
- Implement static module loading
2. **Implement Dependency Resolution**
- Create `internal/service/deps.go`
- Check service dependencies via Consul
- Wait for services to be healthy
3. **Implement Module Initializer**
- Create `internal/module/initializer.go`
- Implement dependency resolution
- Implement initialization
3. **Create Service Bootstrap**
- Create `internal/service/bootstrap.go`
- Common bootstrap pattern
- FX lifecycle integration
4. **Integrate with FX**
- Add lifecycle hooks
- Test initialization
4. **Create Service Template**
- Service template generator
- Example service entry point
5. **Test Service Initialization**
- Test service startup
- Test Consul registration
- Test dependency resolution
## Acceptance Criteria
- [ ] Modules load in correct dependency order
- [ ] Module migrations run automatically
- [ ] Module initialization integrates with FX
- [ ] Lifecycle hooks work correctly
- [ ] Dependency resolution handles cycles
- [ ] Errors are handled gracefully
- [x] Service initialization helpers work correctly
- [x] Services register with Consul automatically
- [x] Service migrations run on startup (per-service schema)
- [x] Service dependency resolution works via Consul
- [x] Services wait for dependencies to be healthy
- [x] FX lifecycle integration works
- [x] Service bootstrap pattern is reusable
- [x] Service template generator creates standard structure
## Related ADRs
- [ADR-0021: Module Loading Strategy](../../adr/0021-module-loading-strategy.md)
- [ADR-0029: Microservices Architecture](../../adr/0029-microservices-architecture.md)
- [ADR-0030: Service Communication Strategy](../../adr/0030-service-communication-strategy.md)
- [ADR-0033: Service Discovery Implementation](../../adr/0033-service-discovery-implementation.md)
## Files to Create/Modify
- `internal/pluginloader/loader.go` - Loader interface
- `internal/pluginloader/static_loader.go` - Static loader
- `internal/pluginloader/plugin_loader.go` - Plugin loader (optional)
- `internal/module/initializer.go` - Module initializer
- `internal/di/container.go` - Integrate module initialization
- `internal/service/init.go` - Service initialization helpers
- `internal/service/deps.go` - Service dependency resolution
- `internal/service/bootstrap.go` - Service bootstrap pattern
- `internal/service/template.go` - Service template generator
- Example: `cmd/blog-service/main.go` - Example service entry point