56 lines
1.8 KiB
Markdown
56 lines
1.8 KiB
Markdown
|
# Project Context
|
|||
|
|
|
|||
|
|
## Purpose
|
|||
|
|
BLS心跳接收端，用于接收并处理Kafka队列中的心跳数据，经过解包处理后写入PostgreSQL数据库。
|
|||
|
|
|
|||
|
|
## Tech Stack
|
|||
|
|
- Node.js (JavaScript)
|
|||
|
|
- Vite (打包工具)
|
|||
|
|
- Kafka (消息队列)
|
|||
|
|
- PostgreSQL (数据库)
|
|||
|
|
- OpenSpec (规范驱动开发框架)
|
|||
|
|
|
|||
|
|
## Project Conventions
|
|||
|
|
|
|||
|
|
### Code Style
|
|||
|
|
- 使用ES模块语法
|
|||
|
|
- 采用2空格缩进
|
|||
|
|
- 变量命名使用小驼峰命名法
|
|||
|
|
- 函数命名使用小驼峰命名法
|
|||
|
|
- 常量命名使用大写下划线分隔
|
|||
|
|
- 文件命名使用kebab-case格式
|
|||
|
|
|
|||
|
|
### Architecture Patterns
|
|||
|
|
- 采用分层架构：数据接入层、业务逻辑层、数据持久化层
|
|||
|
|
- 基于事件驱动模型处理Kafka消息
|
|||
|
|
- 单职责原则，每个模块只负责一个功能
|
|||
|
|
|
|||
|
|
### Testing Strategy
|
|||
|
|
- 使用Mocha进行单元测试
|
|||
|
|
- 测试覆盖率目标：核心功能≥80%
|
|||
|
|
- 每个功能模块都应有对应的测试用例
|
|||
|
|
|
|||
|
|
### Git Workflow
|
|||
|
|
- 采用Git Flow工作流
|
|||
|
|
- 主分支：main (生产环境)
|
|||
|
|
- 开发分支：develop (开发环境)
|
|||
|
|
- 特性分支：feature/xxx (新功能开发)
|
|||
|
|
- 修复分支：hotfix/xxx (紧急修复)
|
|||
|
|
- 提交信息格式：`type(scope): description`
|
|||
|
|
|
|||
|
|
## Domain Context
|
|||
|
|
- BLS：Biometric Login System，生物识别登录系统
|
|||
|
|
- 心跳数据：系统各组件定期发送的状态信息，包含组件ID、状态、时间戳等
|
|||
|
|
- 解包处理：将Kafka消息中的二进制数据转换为结构化数据
|
|||
|
|
|
|||
|
|
## Important Constraints
|
|||
|
|
- 系统需支持高并发，能够处理大量心跳数据
|
|||
|
|
- 数据写入数据库需保证可靠性，避免数据丢失
|
|||
|
|
- 需实现错误重试机制，处理临时网络故障等异常情况
|
|||
|
|
- 系统需具备监控能力，能够实时查看运行状态
|
|||
|
|
|
|||
|
|
## External Dependencies
|
|||
|
|
- Kafka集群：用于接收心跳消息
|
|||
|
|
- PostgreSQL数据库：用于存储心跳数据
|
|||
|
|
- OpenSpec：用于规范驱动开发，确保代码符合设计规范
|