170 lines
5.6 KiB
Markdown
170 lines
5.6 KiB
Markdown
# 开票信息模板重构完成总结
|
||
|
||
## 概述
|
||
|
||
成功创建了专门的开票信息模板表，将开票信息与开票申请进行了完全隔离，实现了更清晰的数据架构和更好的维护性。
|
||
|
||
## 主要变更
|
||
|
||
### 1. 数据库表结构
|
||
|
||
#### 新增表：`user_invoice_info`
|
||
```sql
|
||
CREATE TABLE IF NOT EXISTS user_invoice_info (
|
||
id VARCHAR(36) PRIMARY KEY,
|
||
user_id VARCHAR(36) NOT NULL UNIQUE,
|
||
|
||
-- 开票信息字段
|
||
company_name VARCHAR(200) NOT NULL COMMENT '公司名称',
|
||
taxpayer_id VARCHAR(50) NOT NULL COMMENT '纳税人识别号',
|
||
bank_name VARCHAR(100) COMMENT '开户银行',
|
||
bank_account VARCHAR(50) COMMENT '银行账号',
|
||
company_address VARCHAR(500) COMMENT '企业地址',
|
||
company_phone VARCHAR(20) COMMENT '企业电话',
|
||
receiving_email VARCHAR(100) NOT NULL COMMENT '发票接收邮箱',
|
||
|
||
-- 元数据
|
||
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
|
||
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
|
||
deleted_at TIMESTAMP NULL,
|
||
|
||
-- 索引
|
||
INDEX idx_user_id (user_id),
|
||
INDEX idx_created_at (created_at),
|
||
INDEX idx_updated_at (updated_at)
|
||
);
|
||
```
|
||
|
||
#### 修改表：`invoice_applications`
|
||
- 移除了所有开票信息字段（`company_name`, `taxpayer_id`, `bank_name`, `bank_account`, `company_address`, `company_phone`, `receiving_email`）
|
||
- 新增了 `user_invoice_info_id` 字段，用于关联用户开票信息
|
||
|
||
### 2. 实体层变更
|
||
|
||
#### 新增实体：`UserInvoiceInfo`
|
||
- 位置：`internal/domains/finance/entities/user_invoice_info.go`
|
||
- 包含完整的开票信息字段
|
||
- 提供验证方法：`IsComplete()`, `IsCompleteForSpecialInvoice()`, `GetMissingFields()`
|
||
|
||
#### 修改实体：`InvoiceApplication`
|
||
- 移除了开票信息相关字段
|
||
- 新增 `UserInvoiceInfoID` 字段
|
||
- 更新了工厂方法 `NewInvoiceApplication`
|
||
|
||
### 3. 仓储层变更
|
||
|
||
#### 新增仓储接口：`UserInvoiceInfoRepository`
|
||
- 位置：`internal/domains/finance/repositories/user_invoice_info_repository.go`
|
||
- 提供基本的CRUD操作
|
||
|
||
#### 新增仓储实现：`GormUserInvoiceInfoRepository`
|
||
- 位置：`internal/infrastructure/database/repositories/finance/user_invoice_info_repository_impl.go`
|
||
- 基于GORM的实现
|
||
|
||
#### 修改仓储：`InvoiceApplicationRepository`
|
||
- 移除了 `GetUserInvoiceInfo` 和 `UpdateUserInvoiceInfo` 方法
|
||
- 这些功能现在由专门的 `UserInvoiceInfoRepository` 处理
|
||
|
||
### 4. 服务层变更
|
||
|
||
#### 新增服务：`UserInvoiceInfoService`
|
||
- 位置：`internal/domains/finance/services/user_invoice_info_service.go`
|
||
- 接口和实现放在同一个文件中
|
||
- 提供开票信息的管理功能
|
||
|
||
#### 修改服务：`InvoiceAggregateService`
|
||
- 添加了 `UserInvoiceInfoRepository` 依赖
|
||
- 更新了 `ApplyInvoice` 方法，使用用户开票信息ID
|
||
- 修改了事件发布逻辑，通过关联查询获取邮箱信息
|
||
|
||
### 5. 应用服务层变更
|
||
|
||
#### 修改：`InvoiceApplicationService`
|
||
- 添加了 `UserInvoiceInfoService` 依赖
|
||
- 更新了 `ApplyInvoice` 方法，从用户开票信息获取数据
|
||
- 更新了 `GetUserInvoiceInfo` 和 `UpdateUserInvoiceInfo` 方法
|
||
- 更新了 `GetUserInvoiceRecords` 方法，通过关联查询获取公司名称
|
||
|
||
#### 修改：`AdminInvoiceApplicationService`
|
||
- 添加了 `UserInvoiceInfoRepository` 依赖
|
||
- 更新了 `GetPendingApplications` 方法，通过关联查询获取公司名称和邮箱
|
||
|
||
### 6. 依赖注入配置
|
||
|
||
#### 更新容器配置：`container.go`
|
||
- 添加了 `UserInvoiceInfoRepository` 的依赖注入
|
||
- 添加了 `UserInvoiceInfoService` 的依赖注入
|
||
- 更新了 `InvoiceAggregateService` 的依赖注入
|
||
- 更新了 `InvoiceApplicationService` 和 `AdminInvoiceApplicationService` 的依赖注入
|
||
- 为所有相关服务添加了正确的标签（`fx.ResultTags` 和 `fx.ParamTags`）
|
||
|
||
## 架构优势
|
||
|
||
### 1. 数据隔离
|
||
- 开票信息与申请记录完全分离
|
||
- 避免了数据冗余和不一致问题
|
||
- 提高了数据完整性
|
||
|
||
### 2. 更好的维护性
|
||
- 开票信息的变更不会影响历史申请记录
|
||
- 可以独立管理开票信息的生命周期
|
||
- 便于后续功能扩展
|
||
|
||
### 3. 性能优化
|
||
- 减少了数据冗余
|
||
- 提高了查询效率
|
||
- 更好的索引策略
|
||
|
||
### 4. 业务逻辑清晰
|
||
- 开票信息管理有专门的服务
|
||
- 申请流程更加清晰
|
||
- 便于实现复杂的业务规则
|
||
|
||
## 数据流程
|
||
|
||
### 1. 用户设置开票信息
|
||
```
|
||
用户填写开票信息 → UserInvoiceInfoService.CreateOrUpdateUserInvoiceInfo → UserInvoiceInfoRepository.Save
|
||
```
|
||
|
||
### 2. 用户申请开票
|
||
```
|
||
用户申请开票 → InvoiceApplicationService.ApplyInvoice → 获取用户开票信息 → 创建申请记录（关联开票信息ID）
|
||
```
|
||
|
||
### 3. 管理员处理申请
|
||
```
|
||
管理员处理申请 → 通过关联查询获取开票信息 → 处理申请 → 发送邮件
|
||
```
|
||
|
||
## 兼容性
|
||
|
||
### 1. API接口保持不变
|
||
- 前端API调用方式无需修改
|
||
- 响应数据结构保持一致
|
||
- 向后兼容
|
||
|
||
### 2. 数据库迁移
|
||
- 需要执行新的迁移脚本创建 `user_invoice_info` 表
|
||
- 需要迁移现有数据（如果有的话）
|
||
- 需要更新 `invoice_applications` 表结构
|
||
|
||
## 后续工作
|
||
|
||
### 1. 数据库迁移
|
||
- 执行 `000002_create_user_invoice_info_table.sql` 创建新表
|
||
- 编写数据迁移脚本（如果需要）
|
||
|
||
### 2. 测试验证
|
||
- 单元测试
|
||
- 集成测试
|
||
- 端到端测试
|
||
|
||
### 3. 文档更新
|
||
- API文档更新
|
||
- 数据库设计文档更新
|
||
- 开发指南更新
|
||
|
||
## 总结
|
||
|
||
通过这次重构，我们成功实现了开票信息与开票申请的完全隔离，建立了更清晰的数据架构。新的设计具有更好的可维护性、扩展性和性能，同时保持了API的向后兼容性。这为后续的功能扩展和优化奠定了良好的基础。 |