0x1d
38a251968c
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
90 lines
3.4 KiB
Markdown
90 lines
3.4 KiB
Markdown
# Story 2.6: Database Seeding
|
|
|
|
## Metadata
|
|
- **Story ID**: 2.6
|
|
- **Title**: Database Seeding
|
|
- **Epic**: 2 - Core Services (Authentication & Authorization)
|
|
- **Status**: Pending
|
|
- **Priority**: Medium
|
|
- **Estimated Time**: 4-6 hours
|
|
- **Dependencies**: 2.1, 2.2, 2.3, 2.4
|
|
|
|
## Goal
|
|
Provide database seeding functionality for all services to create initial admin user, default roles, and core permissions. Each service seeds its own database schema.
|
|
|
|
## Description
|
|
This story implements seeding for all core services. Each service has its own seed script that populates its database schema with initial data. The seeding uses service clients where cross-service data is needed (e.g., creating admin user in Identity Service, then assigning admin role via Authz Service).
|
|
|
|
## Deliverables
|
|
|
|
### 1. Identity Service Seeding (`services/identity/internal/seed/seed.go`)
|
|
- Create default admin user (if doesn't exist)
|
|
- Idempotent operations
|
|
- Uses Identity Service's own database connection
|
|
|
|
### 2. Authz Service Seeding (`services/authz/internal/seed/seed.go`)
|
|
- Create default roles (admin, user, guest)
|
|
- Create core permissions
|
|
- Assign core permissions to roles
|
|
- Uses Authz Service's own database connection
|
|
|
|
### 3. Seed Command (`cmd/seed/main.go`)
|
|
- Command-line interface for seeding all services
|
|
- Service-specific seed functions
|
|
- Configuration via environment variables
|
|
- Dry-run mode
|
|
- Verbose logging
|
|
- Uses service clients for cross-service operations (e.g., assign admin role to admin user)
|
|
|
|
### 4. Service-Specific Seed Functions
|
|
- Each service can seed its own schema independently
|
|
- Seed functions are idempotent (safe to run multiple times)
|
|
- Seed functions use service clients when needed
|
|
|
|
### 5. Integration
|
|
- Optional: Auto-seed on first startup in development
|
|
- Manual seeding in production
|
|
- Can be run per-service or all services at once
|
|
|
|
## Acceptance Criteria
|
|
- [x] Identity Service seed creates admin user successfully
|
|
- [x] Authz Service seed creates default roles with proper permissions
|
|
- [x] Seeding is idempotent (can run multiple times safely)
|
|
- [x] Seed command can be run via CLI
|
|
- [x] Seed command uses service clients for cross-service operations
|
|
- [x] Each service seeds its own database schema
|
|
- [x] Admin user can login and manage system after seeding
|
|
|
|
## Related ADRs
|
|
- [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)
|
|
|
|
## Implementation Notes
|
|
- Seeding is typically done once per environment
|
|
- Can be run as a separate command or as part of deployment
|
|
- Uses service clients for cross-service operations (e.g., IdentityServiceClient, AuthzServiceClient)
|
|
- Each service manages its own seed data
|
|
- Seed command coordinates seeding across services
|
|
|
|
## Testing
|
|
```bash
|
|
# Test seeding
|
|
go run cmd/seed/main.go
|
|
|
|
# Test idempotency
|
|
go run cmd/seed/main.go
|
|
go run cmd/seed/main.go # Should be safe to run again
|
|
|
|
# Test service-specific seeding
|
|
go run cmd/seed/main.go --service=identity
|
|
go run cmd/seed/main.go --service=authz
|
|
```
|
|
|
|
## Files to Create/Modify
|
|
- `services/identity/internal/seed/seed.go` - Identity Service seed functions
|
|
- `services/authz/internal/seed/seed.go` - Authz Service seed functions
|
|
- `cmd/seed/main.go` - Seed command (coordinates all services)
|
|
- `Makefile` - Add seed command
|
|
|