266 lines
7.0 KiB
Markdown
266 lines
7.0 KiB
Markdown
# 服务层重构说明
|
||
|
||
## 概述
|
||
|
||
本次重构对项目的服务层进行了全面的职责划分优化，按照DDD（领域驱动设计）原则，将原有的单一服务拆分为多个职责明确的领域服务，并重构了应用服务层，实现了更好的解耦和可维护性。
|
||
|
||
## 重构内容
|
||
|
||
### 1. 用户域 (User Domain)
|
||
|
||
#### 1.1 领域服务拆分
|
||
|
||
**原有服务：**
|
||
- `UserService` - 单一服务，职责混杂
|
||
|
||
**重构后服务：**
|
||
- `UserManagementService` - 用户管理领域服务
|
||
- 负责用户的基本管理操作（创建、查询、更新等）
|
||
- 包含：创建用户、获取用户信息、更新用户信息、检查手机号注册状态等
|
||
|
||
- `UserAuthService` - 用户认证领域服务
|
||
- 负责用户认证相关的业务逻辑
|
||
- 包含：密码验证、登录状态验证、密码修改、密码重置、权限获取等
|
||
|
||
- `SMSCodeService` - 短信验证码服务（保持不变）
|
||
- `EnterpriseService` - 企业信息服务（保持不变）
|
||
|
||
#### 1.2 应用服务重构
|
||
|
||
**重构前：**
|
||
- 直接操作仓库
|
||
- 业务逻辑与数据访问混合
|
||
|
||
**重构后：**
|
||
- 通过领域服务进行业务操作
|
||
- 专注于业务流程编排和数据转换
|
||
- 清晰的业务流程注释
|
||
|
||
### 2. 产品域 (Product Domain)
|
||
|
||
#### 2.1 领域服务拆分
|
||
|
||
**原有服务：**
|
||
- `ProductService` - 单一服务，职责混杂
|
||
|
||
**重构后服务：**
|
||
- `ProductManagementService` - 产品管理领域服务
|
||
- 负责产品的基本管理操作
|
||
- 包含：创建产品、更新产品、删除产品、产品验证、产品查询等
|
||
|
||
- `ProductSubscriptionService` - 产品订阅领域服务
|
||
- 负责产品订阅相关的业务逻辑
|
||
- 包含：订阅验证、创建订阅、获取订阅、取消订阅、订阅统计等
|
||
|
||
#### 2.2 应用服务重构
|
||
|
||
**重构前：**
|
||
- 直接操作仓库
|
||
- 复杂的业务逻辑混合
|
||
|
||
**重构后：**
|
||
- 通过领域服务进行业务操作
|
||
- 简化的业务流程
|
||
- 清晰的数据转换逻辑
|
||
|
||
### 3. 认证域 (Certification Domain)
|
||
|
||
#### 3.1 领域服务拆分
|
||
|
||
**原有服务：**
|
||
- `CertificationService` - 单一服务，职责混杂
|
||
|
||
**重构后服务：**
|
||
- `CertificationManagementService` - 认证管理领域服务
|
||
- 负责认证申请的生命周期管理
|
||
- 包含：创建认证申请、获取认证信息、更新认证状态等
|
||
|
||
- `CertificationWorkflowService` - 认证工作流领域服务
|
||
- 负责认证流程的状态转换和业务逻辑
|
||
- 包含：状态转换、进度计算、权限检查等
|
||
|
||
### 4. 财务域 (Finance Domain)
|
||
|
||
#### 4.1 领域服务完善
|
||
|
||
**原有服务：**
|
||
- `FinanceService` - 过于简单，功能不完整
|
||
|
||
**重构后服务：**
|
||
- `FinanceService` - 完善的财务领域服务
|
||
- 负责财务相关的业务逻辑
|
||
- 包含：钱包管理、余额操作、充值、扣减、余额检查等
|
||
- 使用decimal类型确保金额计算精确性
|
||
|
||
## 架构改进
|
||
|
||
### 1. 职责分离
|
||
|
||
**应用服务层 (Application Layer)：**
|
||
- 负责业务流程编排
|
||
- 负责事务管理
|
||
- 负责数据转换（DTO ↔ 实体）
|
||
- 不直接操作仓库
|
||
|
||
**领域服务层 (Domain Service Layer)：**
|
||
- 负责核心业务逻辑
|
||
- 负责仓库操作
|
||
- 按功能模块划分，职责明确
|
||
|
||
### 2. 依赖关系优化
|
||
|
||
```
|
||
应用服务 → 领域服务 → 仓库
|
||
↓ ↓ ↓
|
||
业务流程 业务逻辑 数据访问
|
||
```
|
||
|
||
### 3. 业务流程示例
|
||
|
||
**用户注册流程：**
|
||
1. 应用服务接收注册命令
|
||
2. 调用短信服务验证验证码
|
||
3. 调用用户管理服务创建用户
|
||
4. 发布用户注册事件
|
||
5. 返回注册响应
|
||
|
||
**产品订阅流程：**
|
||
1. 应用服务接收订阅命令
|
||
2. 调用产品订阅服务验证订阅条件
|
||
3. 调用产品订阅服务创建订阅
|
||
4. 返回订阅响应
|
||
|
||
## 重构收益
|
||
|
||
### 1. 可维护性提升
|
||
|
||
- **单一职责原则**：每个服务只负责特定的业务功能
|
||
- **开闭原则**：新增功能时只需扩展相应的领域服务
|
||
- **依赖倒置**：应用服务依赖领域服务接口，而非具体实现
|
||
|
||
### 2. 可测试性提升
|
||
|
||
- **单元测试**：每个领域服务可以独立测试
|
||
- **集成测试**：应用服务可以mock领域服务进行测试
|
||
- **业务逻辑测试**：核心业务逻辑集中在领域服务中
|
||
|
||
### 3. 可扩展性提升
|
||
|
||
- **功能扩展**：新增业务功能时，只需在相应领域服务中添加方法
|
||
- **服务拆分**：可以根据业务发展需要进一步拆分服务
|
||
- **技术升级**：可以独立升级某个领域的技术栈
|
||
|
||
### 4. 代码质量提升
|
||
|
||
- **代码复用**：领域服务可以被多个应用服务复用
|
||
- **错误处理**：统一的错误处理和日志记录
|
||
- **业务规则**：核心业务规则集中在领域服务中，便于维护
|
||
|
||
## 依赖注入配置
|
||
|
||
### 容器配置更新
|
||
|
||
```go
|
||
// 用户域服务
|
||
userManagementService := user_service.NewUserManagementService(
|
||
userRepo,
|
||
logger,
|
||
)
|
||
userAuthService := user_service.NewUserAuthService(
|
||
userRepo,
|
||
logger,
|
||
)
|
||
|
||
// 产品域服务
|
||
productManagementService := product_service.NewProductManagementService(
|
||
productRepo,
|
||
categoryRepo,
|
||
logger,
|
||
)
|
||
productSubscriptionService := product_service.NewProductSubscriptionService(
|
||
productRepo,
|
||
subscriptionRepo,
|
||
logger,
|
||
)
|
||
|
||
// 认证域服务
|
||
certificationManagementService := certification_service.NewCertificationManagementService(
|
||
certificationRepo,
|
||
enterpriseInfoRepo,
|
||
userRepo,
|
||
logger,
|
||
)
|
||
certificationWorkflowService := certification_service.NewCertificationWorkflowService(
|
||
certificationRepo,
|
||
enterpriseInfoRepo,
|
||
userRepo,
|
||
logger,
|
||
)
|
||
|
||
// 财务域服务
|
||
financeService := finance_service.NewFinanceService(
|
||
walletRepo,
|
||
logger,
|
||
)
|
||
```
|
||
|
||
### 应用服务配置
|
||
|
||
```go
|
||
// 用户应用服务
|
||
userAppService := user.NewUserApplicationService(
|
||
userManagementService,
|
||
userAuthService,
|
||
smsCodeService,
|
||
enterpriseService,
|
||
eventBus,
|
||
jwtAuth,
|
||
logger,
|
||
)
|
||
|
||
// 产品应用服务
|
||
productAppService := product.NewProductApplicationService(
|
||
productManagementService,
|
||
productSubscriptionService,
|
||
logger,
|
||
)
|
||
|
||
// 认证应用服务
|
||
certificationAppService := certification.NewCertificationApplicationService(
|
||
certificationManagementService,
|
||
certificationWorkflowService,
|
||
enterpriseService,
|
||
eventBus,
|
||
logger,
|
||
)
|
||
```
|
||
|
||
## 后续优化建议
|
||
|
||
### 1. 进一步拆分
|
||
|
||
- **用户域**：可以考虑将权限管理独立为 `UserPermissionService`
|
||
- **产品域**：可以考虑将库存管理独立为 `ProductInventoryService`
|
||
- **财务域**：可以考虑将交易记录独立为 `TransactionService`
|
||
|
||
### 2. 接口抽象
|
||
|
||
- 为每个领域服务定义接口
|
||
- 便于测试和依赖注入
|
||
- 提高代码的可扩展性
|
||
|
||
### 3. 事件驱动
|
||
|
||
- 在领域服务中发布领域事件
|
||
- 实现更松散的耦合
|
||
- 支持异步业务处理
|
||
|
||
### 4. 缓存优化
|
||
|
||
- 在领域服务中添加缓存逻辑
|
||
- 提高查询性能
|
||
- 减少数据库压力
|
||
|
||
## 总结
|
||
|
||
本次重构成功实现了服务层的职责分离，建立了清晰的架构层次，提高了代码的可维护性、可测试性和可扩展性。通过DDD原则的实践，为项目的长期发展奠定了良好的基础。 |