3.2 Service：业务逻辑的施工层

3.2 Service：业务逻辑封装与复用

在现代 Web 应用架构中，如何组织和管理日益复杂的业务逻辑，始终是开发者面临的核心挑战之一。Egg.js 作为一款面向企业级应用的 Node.js 框架，其设计理念强调“约定优于配置”与“分层清晰”，而 Service 层正是这一理念的关键体现。它不仅承载着业务规则的实现，更是实现代码可维护性、可测试性与高内聚低耦合架构的重要支柱。

那么，Service 究竟是什么？为何它在 Egg.js 的整体架构中占据如此核心的地位？我们不妨从一个朴素的问题出发：当一个 HTTP 请求到达控制器（Controller）时，我们是否应该直接在 Controller 中编写数据库查询、第三方 API 调用、复杂计算或状态校验？答案显然是否定的。若将业务逻辑散落在 Controller、中间件甚至路由配置中，系统将迅速陷入“意大利面条式代码”的泥沼——难以理解、难以修改、更难以复用。

Egg.js 的 Service 机制，正是对这一问题的优雅回应。它提供了一个标准化的抽象层，用于封装所有与具体业务场景相关的操作逻辑，使 Controller 仅专注于请求解析与响应构造，从而实现关注点分离（Separation of Concerns）。这种设计并非凭空而来，而是深深植根于经典的分层架构思想——如 MVC（Model-View-Controller）的演化版本，或更贴近后端服务的“Controller-Service-DAO”三层模型。

核心概念：Service 的角色与定位

在 Egg.js 的上下文中，Service 是一个由框架自动加载并注入到 Context（ctx）中的类实例。每个 Service 类通常对应一个特定的业务领域，例如 UserService、OrderService 或 PaymentService。开发者通过继承 egg.Service 基类，定义自己的业务方法，并通过 ctx.service.xxx.yyy() 的方式在 Controller、其他 Service 甚至定时任务中调用。

值得注意的是，Service 并非数据模型（Model）本身。虽然它常常与 Model 协同工作（例如调用 Sequelize 或 Mongoose 模型进行数据库操作），但其职责远不止于此。Service 是业务规则的执行者，是跨模型协作的协调者，是外部依赖的适配器。它回答的问题不是“数据长什么样”，而是“在这个业务场景下，我们应该做什么”。

举个例子：用户注册流程。表面上看，这只是一个“插入一条用户记录”的操作。但在真实业务中，可能涉及邮箱格式校验、密码强度检查、唯一性验证、发送欢迎邮件、记录审计日志、触发积分发放等多个步骤。若将这些逻辑全部塞进 Controller，不仅代码臃肿，且无法在“管理员后台手动创建用户”或“第三方 OAuth 登录”等其他入口复用。而将这些逻辑封装在 UserService.register() 方法中，则实现了逻辑的集中管理与无缝复用。

上图清晰展示了 Service 作为业务中枢的角色：它聚合了对多个底层资源（数据库、邮件服务、日志系统）的操作，并将它们编织成一个完整的业务事务。

技术细节：Service 的生命周期与依赖注入

Egg.js 对 Service 的管理高度自动化。框架在应用启动时，会扫描 app/service 目录（及其子目录）下的所有 .js 文件，并根据文件路径和类名自动生成服务实例。例如，app/service/user/profile.js 中导出的 Profile 类，将被挂载为 ctx.service.user.profile。

每个 Service 实例的生命周期与当前请求的 Context 绑定。这意味着，在同一个请求处理过程中，多次访问 ctx.service.xxx 将返回同一个实例，从而保证了状态的一致性（尽管通常建议 Service 保持无状态）。这种设计避免了不必要的对象重复创建，也使得在 Service 内部缓存临时计算结果成为可能。

更重要的是，Service 天然享有 Egg.js 强大的依赖注入能力。通过 this.ctx，Service 可以访问到当前请求的完整上下文，包括：

this.ctx.model：访问 ORM 模型；
this.ctx.config：读取应用配置；
this.ctx.logger：使用统一的日志接口；
this.ctx.curl：发起 HTTP 请求；
以及其他 Service（通过 this.ctx.service）。

这种基于 Context 的隐式依赖注入，既简化了代码（无需手动传递依赖），又保持了良好的解耦性。Service 不需要知道 Model 或 Logger 的具体实现，只需通过约定的接口调用即可。这种“面向接口编程”的思想，正是构建可测试、可替换系统的关键。

实现方法：编写高质量 Service 的最佳实践

编写一个有效的 Service 并非简单地把逻辑从 Controller 搬过来。真正的挑战在于如何设计 Service 的边界、粒度与内部结构。以下是几条经过实践检验的原则：

第一，单一职责原则（SRP）。一个 Service 方法应当只做一件事，并将其做好。避免出现名为 handleUserRequest 的“上帝方法”，它试图处理注册、登录、信息更新等所有用户相关操作。相反，应拆分为 register()、login()、updateProfile() 等细粒度方法。这不仅提高了可读性，也为单元测试提供了便利。

第二，事务边界控制。当一个业务操作涉及多个数据库写入时，必须确保其原子性。Egg.js 本身不强制事务管理，但通过与 ORM（如 Sequelize）的集成，可以在 Service 中显式开启事务。例如：


// app/service/order.js
const { Service } = require('egg');
class OrderService extends Service {
  async createOrder(orderData) {
    const { ctx, app } = this;
    const transaction = await app.model.transaction();
    try {
      const order = await ctx.model.Order.create(orderData, { transaction });
      await ctx.model.Inventory.decrease(order.productId, order.quantity, { transaction });
      await transaction.commit();
      return order;
    } catch (err) {
      await transaction.rollback();
      throw err; // 重要：必须重新抛出错误，否则上层无法感知失败
    }
  }
}

在此例中，订单创建与库存扣减被包裹在一个数据库事务中，确保了数据一致性。这种事务控制逻辑放在 Service 层是最合适的，因为它是业务规则的一部分。

第三，错误处理与语义化。Service 应抛出具有业务语义的错误，而非原始的技术异常。例如，当用户尝试注册已存在的邮箱时，不应简单抛出数据库唯一索引冲突错误，而应抛出一个自定义的 UserEmailAlreadyExistsError。Controller 可以捕获此类错误，并映射为对应的 HTTP 状态码（如 409 Conflict）和用户友好的消息。这种分层错误处理机制，使得系统更具健壮性和可维护性。

第四，避免循环依赖。由于 Service 可以相互调用，若设计不当，极易形成 A 调用 B、B 又调用 A 的循环依赖。这不仅导致逻辑混乱，还可能引发无限递归。解决之道在于引入更高层次的协调者（如 Application Service），或将公共逻辑提取到独立的工具类或 Domain Service 中。

应用场景：Service 在复杂业务中的价值凸显

Service 的价值在简单 CRUD 场景中或许不那么明显，但一旦业务复杂度提升，其优势便无可替代。

场景一：跨域业务编排。假设一个电商平台的“下单”操作，需要同时与用户服务、商品服务、库存服务、优惠券服务、支付网关交互。若将这些调用分散在 Controller 中，代码将变得极其脆弱且难以追踪。而通过一个 OrderService.placeOrder() 方法进行统一编排，不仅逻辑清晰，还可方便地加入重试、熔断、异步化等高级策略。

场景二：多端复用。同一套业务逻辑，往往需要服务于 Web 前端、移动 App、微信小程序、甚至内部管理后台。若业务逻辑散落在各端的 Controller 中，任何规则变更都将导致多处修改，极易出错。而将核心逻辑沉淀在 Service 层，则实现了“一次编写，处处调用”，极大提升了开发效率与系统一致性。

场景三：测试驱动开发（TDD）。由于 Service 是纯 JavaScript 类，且依赖通过 Context 注入，我们可以轻松地对其进行单元测试。通过模拟（Mock）ctx.model、ctx.curl 等依赖，可以隔离地验证业务逻辑的正确性，而无需启动整个应用或连接真实数据库。这种可测试性，是构建高质量软件的基石。

优缺点分析：理性看待 Service 模式

任何架构模式都有其适用边界。Service 模式虽好，亦非万能。

优点显而易见：

高内聚：相关业务逻辑集中管理，便于理解和维护。
低耦合：Controller 与业务逻辑解耦，Controller 变得轻薄。
强复用：逻辑可在不同入口（HTTP、定时任务、消息队列消费者）复用。
易测试：业务逻辑可独立于网络层进行单元测试。
清晰分层：符合软件工程的分层思想，有利于团队协作。

然而，潜在的缺点也不容忽视：

过度抽象风险：对于极其简单的操作（如仅查询单表），强行引入 Service 可能增加不必要的间接层，使代码显得“过度设计”。
学习曲线：新手开发者可能难以把握 Service 与 Model、Helper 之间的职责边界，导致职责混淆。
调试复杂性：当 Service 调用链过深时，错误堆栈可能变得冗长，定位问题需要更多上下文切换。

因此，关键在于适度。Egg.js 并未强制要求所有逻辑都必须进入 Service，而是提供了一种推荐的最佳实践。开发者应根据业务复杂度、团队规模和长期维护成本，灵活判断何时使用 Service。

3.2 Service：业务逻辑的施工层

3.2 Service：业务逻辑封装与复用

3.2 Service：业务逻辑封装与复用

核心概念：Service 的角色与定位

技术细节：Service 的生命周期与依赖注入

实现方法：编写高质量 Service 的最佳实践

应用场景：Service 在复杂业务中的价值凸显

优缺点分析：理性看待 Service 模式

最新进展与未来展望