hailin
931055b51f
feat(admin): add conversation management with device tracking display
...
## Backend (conversation-service)
- Add AdminConversationController with JWT auth for admin API
- Endpoints: list conversations, by user, detail, messages, statistics
- Support filtering by status, userId, date range, conversion
- Add JWT_SECRET environment variable to docker-compose.yml
- Add jsonwebtoken dependency for admin token verification
## Frontend (admin-client)
### New Features:
- Add conversations feature module with:
- API layer (conversations.api.ts)
- React Query hooks (useConversations.ts)
- ConversationsPage with full management UI
### User Management Enhancement:
- Add "最近咨询记录" section in user detail drawer
- Display device info for each conversation:
- IP address with region
- User-Agent (parsed to browser/OS)
- Device fingerprint
- Show conversation status, conversion status, message count
### Navigation:
- Add "对话管理" menu item with MessageOutlined icon
- Add /conversations route
## Files Added:
- admin-conversation.controller.ts (backend admin API)
- conversations feature folder (frontend)
- infrastructure/conversations.api.ts
- application/useConversations.ts
- presentation/pages/ConversationsPage.tsx
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-25 10:04:17 -08:00
hailin
afd707d15f
refactor(services): implement 4-layer Clean Architecture for all backend services
...
Refactored all 6 backend services to 4-layer Clean Architecture pattern
following knowledge-service as reference implementation.
## Architecture Pattern (4-Layer)
```
src/
├── domain/ # Pure business entities and interfaces
│ ├── entities/ # Domain entities (no ORM decorators)
│ ├── repositories/ # Repository interfaces + Symbol tokens
│ └── value-objects/ # Enums and value types
├── application/
│ ├── dtos/ # Data transfer objects
│ └── services/ # Application services (use case orchestration)
├── adapters/
│ ├── inbound/ # Controllers, gateways (API endpoints)
│ └── outbound/
│ ├── persistence/ # Repository implementations
│ ├── clients/ # External service clients
│ └── storage/ # File storage adapters
└── infrastructure/
└── database/postgres/
└── entities/ # ORM entities with decorators
```
## Services Refactored
### user-service
- adapters/inbound: AuthController, UserController
- adapters/outbound/persistence: UserPostgresRepository, VerificationCodePostgresRepository
- application/services: AuthService, UserService
- application/dtos: AuthDto, UserDto
### payment-service
- adapters/inbound: OrderController, PaymentController
- adapters/outbound/persistence: OrderPostgresRepository, PaymentPostgresRepository
- adapters/outbound/payment-methods: AlipayAdapter, WechatPayAdapter, StripeAdapter
- application/services: OrderService, PaymentService
- application/dtos: OrderDto, PaymentDto
### file-service
- adapters/inbound: FileController
- adapters/outbound/persistence: FilePostgresRepository
- adapters/outbound/storage: MinioStorageAdapter
- application/services: FileService
- application/dtos: UploadFileDto
### conversation-service
- adapters/inbound: ConversationController, InternalController, ConversationGateway
- adapters/outbound/persistence: ConversationPostgresRepository, MessagePostgresRepository, TokenUsagePostgresRepository
- application/services: ConversationService
- application/dtos: ConversationDto
### knowledge-service
- adapters/inbound: KnowledgeController, MemoryController, InternalMemoryController
- adapters/outbound/persistence: KnowledgePostgresRepository, MemoryPostgresRepository
- application/services: KnowledgeService, MemoryService
- application/dtos: KnowledgeDto, MemoryDto
### evolution-service
- domain/entities: AdminEntity
- domain/repositories: IAdminRepository (Symbol-based DI)
- domain/value-objects: AdminRole enum
- adapters/inbound: AdminController, EvolutionController
- adapters/outbound/persistence: AdminPostgresRepository
- adapters/outbound/clients: ConversationClient, KnowledgeClient
- application/services: AdminService, EvolutionService
- application/dtos: AdminDto, EvolutionDto
- infrastructure/database/postgres/entities: AdminORM
## Key Improvements
- Symbol-based dependency injection for repository interfaces
- ORM entities separated from domain entities
- Consistent 4-layer structure across all services
- DTOs for API contracts
- Clear separation: domain logic vs infrastructure concerns
## Configuration
- Updated turbo.json: renamed "pipeline" to "tasks" for Turbo 2.0+
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-24 22:18:22 -08:00
hailin
02954f56db
refactor(services): implement Clean Architecture across 4 services
...
## Overview
Refactor user-service, payment-service, file-service, and conversation-service
to follow Clean Architecture pattern based on knowledge-service reference.
## Architecture Pattern Applied
```
src/
├── domain/
│ ├── entities/ # Pure domain entities (no ORM decorators)
│ └── repositories/ # Repository interfaces + Symbol DI tokens
├── infrastructure/
│ └── database/postgres/
│ ├── entities/ # ORM entities with TypeORM decorators
│ └── *-postgres.repository.ts # Repository implementations
└── {feature}/
└── {feature}.module.ts # DI configuration with Symbol providers
```
## Changes by Service
### user-service (40% → 100% compliant)
- Created: IUserRepository, IVerificationCodeRepository interfaces
- Created: UserORM, VerificationCodeORM entities
- Created: UserPostgresRepository, VerificationCodePostgresRepository
- Modified: UserEntity, VerificationCodeEntity → pure domain with factory methods
- Updated: user.module.ts, auth.module.ts with Symbol-based DI
### payment-service (50% → 100% compliant)
- Created: IOrderRepository, IPaymentRepository interfaces
- Created: OrderORM, PaymentORM entities
- Created: OrderPostgresRepository, PaymentPostgresRepository
- Modified: OrderEntity, PaymentEntity → pure domain with factory methods
- Updated: order.module.ts, payment.module.ts with Symbol-based DI
### file-service (40% → 100% compliant)
- Created: IFileRepository interface
- Created: FileORM entity
- Created: FilePostgresRepository
- Modified: FileEntity → pure domain with factory methods
- Updated: file.module.ts with Symbol-based DI
### conversation-service (60% → 100% compliant)
- Created: IConversationRepository, IMessageRepository, ITokenUsageRepository
- Created: ConversationORM, MessageORM, TokenUsageORM entities
- Created: ConversationPostgresRepository, MessagePostgresRepository,
TokenUsagePostgresRepository
- Modified: ConversationEntity, MessageEntity, TokenUsageEntity → pure domain
- Updated: conversation.module.ts with Symbol-based DI
- Updated: app.module.ts, data-source.ts entity patterns
## Key Implementation Details
1. **Symbol-based DI Pattern**:
```typescript
export const USER_REPOSITORY = Symbol('IUserRepository');
@Module({
providers: [{ provide: USER_REPOSITORY, useClass: UserPostgresRepository }],
exports: [UserService, USER_REPOSITORY],
})
```
2. **Pure Domain Entities**: Factory methods `create()` and `fromPersistence()`
for controlled instantiation without ORM decorators
3. **Repository Implementations**: Include `toORM()` and `toEntity()` conversion
methods for anti-corruption layer between domain and infrastructure
4. **Entity Discovery**: Changed glob pattern from `*.entity` to `*.orm`
in app.module.ts and data-source.ts files
## Breaking Changes
- None for API consumers
- Internal architecture restructuring only
## Testing
- All 4 services compile successfully with `pnpm build`
- Database schema compatibility verified (column mappings preserved)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-24 21:18:25 -08:00
hailin
e1bcd0145e
refactor(evolution): use API instead of shared database tables
...
Breaking change: evolution-service no longer directly accesses
conversations and messages tables.
Changes:
- Add internal API endpoints to conversation-service for service-to-service calls
- Create ConversationClient in evolution-service to call conversation-service API
- Remove ConversationORM and MessageORM from evolution-service
- Update evolution.service to use ConversationClient
This follows microservices best practices:
- Each service owns its data
- Services communicate via API, not shared tables
TODO: Apply same pattern to system_experiences (knowledge-service)
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
2026-01-24 19:48:09 -08:00
hailin