tyapi-server/docs/服务层重构说明.md

服务层重构说明

概述

本次重构对项目的服务层进行了全面的职责划分优化，按照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. 代码质量提升

• 代码复用：领域服务可以被多个应用服务复用
• 错误处理：统一的错误处理和日志记录
• 业务规则：核心业务规则集中在领域服务中，便于维护

依赖注入配置

容器配置更新

// 用户域服务
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,
)

应用服务配置

// 用户应用服务
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原则的实践，为项目的长期发展奠定了良好的基础。