fengling-activity/docs/NAMING_CONVENTION.md
sam ab8d12527e refactor: major project restructuring and cleanup
Changes:

- Remove deprecated Fengling.Activity and YarpGateway.Admin projects

- Add points processing services with distributed lock support

- Update Vben frontend with gateway management pages

- Add gateway config controller and database listener

- Update routing to use header-mixed-nav layout

- Add comprehensive test suites for Member services

- Add YarpGateway integration tests

- Update package versions in Directory.Packages.props

Ultraworked with [Sisyphus](https://github.com/code-yeongyu/oh-my-opencode)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>
2026-02-15 10:34:07 +08:00

199 lines
4.5 KiB
Markdown

# Service Naming Convention
## Overview
This document defines the naming convention for all microservices in the Fengling platform.
## URL Structure
```
{ServicePrefix}/{Version}/{Resource}/{Action}
```
### Components
| Component | Description | Examples |
|-----------|-------------|----------|
| ServicePrefix | Unique service identifier | `activity`, `member`, `order` |
| Version | API version | `v1`, `v2` |
| Resource | Domain entity or resource | `campaigns`, `users`, `orders` |
| Action | Optional action endpoint | `publish`, `cancel` |
## Service Registry
| Service | Prefix | Port | Health Endpoint |
|---------|--------|------|-----------------|
| Activity | `activity` | 5001 | `/health` |
| Member | `member` | 5002 | `/health` |
| Order | `order` | 5003 | `/health` |
| Payment | `payment` | 5004 | `/health` |
| RiskControl | `risk` | 5005 | `/health` |
## Cluster Naming Convention
```
{ServicePrefix}-service
```
Examples:
- `activity-service`
- `member-service`
- `order-service`
- `payment-service`
- `risk-service`
## Gateway Route Configuration
### Global Route Pattern
```
/{ServicePrefix}/{**path} -> {ServicePrefix}-service
```
### Examples
**Activity Service:**
```yaml
Route:
PathPattern: /activity/v1/{**path}
ClusterId: activity-service
Endpoints:
GET /activity/v1/campaigns # List campaigns
POST /activity/v1/campaigns # Create campaign
GET /activity/v1/campaigns/{id} # Get campaign
POST /activity/v1/campaigns/{id}/publish # Publish campaign
```
**Member Service:**
```yaml
Route:
PathPattern: /member/v1/{**path}
ClusterId: member-service
Endpoints:
GET /member/v1/users # List users
POST /member/v1/users # Create user
GET /member/v1/users/{id} # Get user
PUT /member/v1/users/{id} # Update user
```
**Order Service:**
```yaml
Route:
PathPattern: /order/v1/{**path}
ClusterId: order-service
Endpoints:
GET /order/v1/orders # List orders
POST /order/v1/orders # Create order
GET /order/v1/orders/{id} # Get order
PUT /order/v1/orders/{id}/cancel # Cancel order
```
## Gateway Registration
### Activity Service Registration Script
```bash
# Register Activity Service
./scripts/gateway/register-service.sh \
--service-prefix "activity" \
--gateway-url "http://localhost:5000" \
--address "http://localhost:5001"
# After registration, access endpoints at:
# GET http://localhost:5000/activity/v1/campaigns
# POST http://localhost:5000/activity/v1/campaigns
```
## Versioning Strategy
### Version Lifecycle
| Version | Status | Description |
|---------|--------|-------------|
| v1 | Active | Current stable API |
| v2 | Planning | Next major version |
| beta | Testing | Beta releases |
### Versioning Rules
1. **Major Version** (`v1`, `v2`): Breaking changes require version bump
2. **Minor Updates**: Backward-compatible additions don't require version change
3. **Deprecation**: Old versions should be supported for at least 6 months
## Multi-Tenancy Support
### Tenant-Specific Routes
For dedicated tenant instances:
```
/tenant/{tenantCode}/{ServicePrefix}/{Version}/{**path}
```
Example:
```
/tenant/acme/activity/v1/campaigns
```
## Health Check Endpoints
| Service | Health Path |
|---------|-------------|
| Activity | `/health` |
| Member | `/health` |
| Order | `/health` |
| Payment | `/health` |
| Risk | `/health` |
## Monitoring & Metrics
### Service Labels
| Label | Value |
|-------|-------|
| service | `activity` |
| version | `v1` |
| tenant | `{tenantCode}` |
## Best Practices
### 1. Consistent Naming
- Use lowercase for all components
- Use hyphens for multi-word names: `risk-control` NOT `riskControl`
- Avoid abbreviations: `campaigns` NOT `cmps`
### 2. Resource Naming
- Use plural nouns for collections: `campaigns` NOT `campaignList`
- Use singular for single resources: `campaign/{id}` NOT `campaigns/{id}`
### 3. Action Endpoints
- Use HTTP verbs for CRUD: `GET`, `POST`, `PUT`, `DELETE`
- Use specific verbs for actions: `publish`, `cancel`, `activate`
### 4. Path Parameters
- Use descriptive names: `/campaigns/{campaignId}` NOT `/campaigns/{id}`
- Consistent parameter naming across services
## Migration Guide
### Updating Existing Routes
**Before:**
```
/api/campaigns
/api/orders
```
**After:**
```
/activity/v1/campaigns
/order/v1/orders
```
**Migration Strategy:**
1. Register new routes with v1
2. Keep old routes active (alias)
3. Update clients to use new format
4. Remove old routes after transition period