# 服务层重构说明

## 概述

本次重构对项目的服务层进行了全面的职责划分优化，按照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原则的实践，为项目的长期发展奠定了良好的基础。