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,57 +1,82 @@
# Epic 2: Authentication & Authorization
# Epic 2: Core Services (Authentication & Authorization)
## Overview
Implement complete JWT-based authentication system, build comprehensive identity management with user lifecycle, create role-based access control (RBAC) system, implement authorization middleware and permission checks, add comprehensive audit logging for security compliance, and provide database seeding for initial setup. All core services (Auth, Identity, Authz, Audit) are independent microservices that expose gRPC servers and register with the service registry.
Implement Auth, Identity, Authz, and Audit as **separate, independent microservices**. Each service has its own entry point (`cmd/{service}/`), gRPC server, database connection/schema, and registers with Consul service registry. Services communicate via service clients (gRPC) and use service discovery.
**Key Principle:** Each service is independently deployable from day one.
## Stories
### 2.1 JWT Authentication System
- [Story: 2.1 - JWT Authentication](./2.1-jwt-authentication.md)
- **Goal:** Implement a complete JWT-based authentication system with access tokens, refresh tokens, and secure token management.
- **Deliverables:** Authentication interfaces, JWT implementation, authentication middleware, login/refresh endpoints
### 2.1 Auth Service - JWT Authentication
- [Story: 2.1 - Auth Service](./2.1-jwt-authentication.md)
- **Goal:** Implement Auth Service as independent microservice with JWT token generation/validation.
- **Deliverables:**
- Service entry point: `cmd/auth-service/main.go`
- gRPC server implementation
- Database connection and schema (auth schema)
- Service registration with Consul
- JWT token generation/validation logic
### 2.2 Identity Management System
- [Story: 2.2 - Identity Management](./2.2-identity-management.md)
- **Goal:** Build a complete user identity management system with registration, email verification, password management, and user CRUD operations.
- **Deliverables:** Identity interfaces, user repository, user service, user management API endpoints
### 2.2 Identity Service - User Management
- [Story: 2.2 - Identity Service](./2.2-identity-management.md)
- **Goal:** Implement Identity Service as independent microservice for user CRUD and password management.
- **Deliverables:**
- Service entry point: `cmd/identity-service/main.go`
- gRPC server implementation
- Database connection and schema (identity schema with User entity)
- Service registration with Consul
- User CRUD, password management, email verification
### 2.3 Role-Based Access Control (RBAC) System
- [Story: 2.3 - RBAC System](./2.3-rbac-system.md)
- **Goal:** Implement a complete RBAC system with permissions, role management, and authorization middleware.
- **Deliverables:** Permission system, permission resolver, authorization system, authorization middleware
### 2.3 Authz Service - Authorization & RBAC
- [Story: 2.3 - Authz Service](./2.3-rbac-system.md)
- **Goal:** Implement Authz Service as independent microservice for permission resolution and authorization.
- **Deliverables:**
- Service entry point: `cmd/authz-service/main.go`
- gRPC server implementation
- Database connection and schema (authz schema with Role, Permission entities)
- Service registration with Consul
- Permission resolution, RBAC/ABAC authorization
### 2.4 Role Management API
### 2.4 Role Management (Part of Authz Service)
- [Story: 2.4 - Role Management](./2.4-role-management.md)
- **Goal:** Provide complete API for managing roles, assigning permissions to roles, and assigning roles to users.
- **Deliverables:** Role repository, role management API endpoints, authorization and validation
- **Goal:** Extend Authz Service with role management API.
- **Deliverables:**
- Role management gRPC endpoints
- Role assignment to users (via Identity Service client)
- Permission assignment to roles
### 2.5 Audit Logging System
- [Story: 2.5 - Audit Logging](./2.5-audit-logging.md)
- **Goal:** Implement comprehensive audit logging that records all security-sensitive actions for compliance and security monitoring.
- **Deliverables:** Audit interface, audit implementation, audit middleware, audit log query API
### 2.5 Audit Service - Audit Logging
- [Story: 2.5 - Audit Service](./2.5-audit-logging.md)
- **Goal:** Implement Audit Service as independent microservice for audit logging.
- **Deliverables:**
- Service entry point: `cmd/audit-service/main.go`
- gRPC server implementation
- Database connection and schema (audit schema with AuditLog entity)
- Service registration with Consul
- Audit log recording and querying
### 2.6 Database Seeding and Initialization
### 2.6 Database Seeding
- [Story: 2.6 - Database Seeding](./2.6-database-seeding.md)
- **Goal:** Provide database seeding functionality to create initial admin user, default roles, and core permissions.
- **Deliverables:** Seed script, seed command, integration with application startup
### 2.7 Service Client Interfaces
- [Story: 2.7 - Service Client Interfaces](./2.7-service-abstraction-layer.md) (moved from Epic 1)
- **Goal:** Create service client interfaces for all core services to enable microservices communication.
- **Deliverables:** Service client interfaces, service factory, configuration
- **Goal:** Provide seeding for all services (initial admin user, default roles, permissions).
- **Deliverables:**
- Seed scripts for each service
- Seed commands
- Integration with service startup
## Deliverables Checklist
- [ ] JWT authentication with access/refresh tokens
- [ ] User CRUD with email verification
- [ ] Role and permission management
- [ ] Authorization middleware
- [ ] Audit logging for all actions
- [ ] Seed script for initial data
- [ ] Auth Service: Independent service with gRPC server, database schema, Consul registration
- [ ] Identity Service: Independent service with gRPC server, User entity, Consul registration
- [ ] Authz Service: Independent service with gRPC server, Role/Permission entities, Consul registration
- [ ] Audit Service: Independent service with gRPC server, AuditLog entity, Consul registration
- [ ] All services use service clients for inter-service communication
- [ ] All services have their own database connection pools and schemas
- [ ] Seed scripts for all services
## Acceptance Criteria
- User can register and login
- JWT tokens are validated on protected routes
- Users without permission get 403
- All actions are logged in audit table
- Admin can create roles and assign permissions
- Integration test: user without permission cannot access protected resource
- Each service is independently deployable
- Each service has its own entry point (`cmd/{service}/main.go`)
- Each service registers with Consul service registry
- Services communicate via gRPC through service clients
- Each service has its own database schema
- API Gateway can route to all services via service discovery
- Integration test: Services can discover and communicate with each other