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
40 lines
2.0 KiB
Markdown
40 lines
2.0 KiB
Markdown
# Epic 4: Sample Feature Service (Blog Service)
|
|
|
|
## Overview
|
|
Create a complete sample feature service (Blog Service) to demonstrate the framework. The Blog Service is an independent service with its own entry point (`cmd/blog-service/`), gRPC server, and database schema. It uses service clients to communicate with core services (Auth, Identity, Authz, Audit). This serves as a reference implementation for future developers creating feature services.
|
|
|
|
**Key Principle:** Blog Service demonstrates how to create a feature service that integrates with the platform using service clients and Consul service discovery.
|
|
|
|
## Stories
|
|
|
|
### 4.1 Complete Blog Service
|
|
- [Story: 4.1 - Blog Service](./4.1-blog-module.md)
|
|
- **Goal:** Create a complete sample blog service to demonstrate the framework.
|
|
- **Deliverables:** Complete blog service with entry point, gRPC server, database schema, CRUD operations, permissions, service client integration, and integration tests
|
|
|
|
## Deliverables Checklist
|
|
- [ ] Blog service entry point (`cmd/blog-service/main.go`)
|
|
- [ ] Blog service directory structure (`services/blog/`)
|
|
- [ ] gRPC service definition (`api/proto/blog.proto`)
|
|
- [ ] gRPC server implementation
|
|
- [ ] Service manifest defines permissions
|
|
- [ ] Blog post domain model defined
|
|
- [ ] Ent schema for blog posts (blog schema)
|
|
- [ ] Repository implements CRUD operations
|
|
- [ ] Service layer implements business logic
|
|
- [ ] Service uses service clients (Identity, Authz, Audit)
|
|
- [ ] Service registers with Consul
|
|
- [ ] Integration tests passing
|
|
|
|
## Acceptance Criteria
|
|
- Blog service is independently deployable
|
|
- Service entry point exists at `cmd/blog-service/main.go`
|
|
- Service registers with Consul on startup
|
|
- gRPC server starts on configured port
|
|
- CRUD operations work for blog posts
|
|
- Service uses IdentityServiceClient for user operations
|
|
- Service uses AuthzServiceClient for authorization
|
|
- Service uses AuditServiceClient for audit logging
|
|
- Service has its own database schema (blog schema)
|
|
- Service can be discovered by API Gateway via Consul
|