服务层与领域模型分离的架构实践

本文深入剖析了现代MVC架构中服务层与领域模型分离的必要性与实践路径，直击初学者常犯的“复合控制器”误区——即让OrderController直接组合多个子控制器来处理跨表业务，指出这种做法会导致职责混乱、测试困难、事务失控和领域逻辑泄露；文章倡导清晰的四层分层架构：控制器专注请求响应、应用服务层（如OrderService）统一编排业务用例与事务、领域模型内聚封装业务规则与状态、基础设施层隔离技术细节，通过电商订单这一典型场景，展示了如何真正实现高内聚、低耦合、可测试、易演进的领域驱动式架构。

在现代MVC架构中，控制器不应直接操作多个数据表或组合多个子控制器；正确的做法是将跨表业务逻辑封装在独立的服务层（如OrderService），由控制器仅负责协调请求与响应，而数据访问则严格委托给数据映射器（Data Mapper）。

在现代MVC架构中，控制器不应直接操作多个数据表或组合多个子控制器；正确的做法是将跨表业务逻辑封装在独立的服务层（如OrderService），由控制器仅负责协调请求与响应，而数据访问则严格委托给数据映射器（Data Mapper）。

当处理像电商订单（Order）这样天然聚合多张表（orders、order_items、order_sellers、order_buyer等）的业务实体时，初学者常倾向于设计一个“复合控制器”——例如 OrderController 内部持有 OrderInfoController、OrderItemController 等多个控制器实例，并在 create()、get() 等方法中依次调用它们。这种做法看似直观，实则严重违背分层架构原则，会导致控制器职责膨胀、测试困难、数据库耦合加剧，且难以应对事务一致性、并发控制和领域规则校验等核心需求。

✅ 正确的架构路径是职责分离 + 分层抽象：

• 控制器（Controller）：仅解析HTTP请求、校验基础输入（如参数格式）、调用服务层、返回响应。它不包含SQL、不操作模型对象、不管理事务。
• 应用服务层（Application Service / Use Case）：例如 OrderService，是业务逻辑的真正承载者。它协调多个领域对象（如 Order、OrderItem）、调用多个仓储（Repository）或集合（Collection），并包裹完整事务。这是实现“创建一个订单及其全部子项”的唯一合理位置。
• 领域模型层（Domain Model）：定义业务本质，如 Order 实体类应内聚地管理其状态（如总金额计算、库存预占校验）、生命周期规则（如“已支付订单不可修改收货地址”）。它完全 unaware of数据库、HTTP 或框架。
• 基础设施层（Infrastructure）：仅在此处出现具体技术细节。OrderDataMapper 或 OrderRepository 的实现类（如 PdoOrderMapper）负责执行 JOIN 查询、批量插入、事务提交等，且可自由使用任意 SQL（包括跨表关联查询），但对外仅暴露领域接口。

以下是一个精简但生产就绪的 OrderService 示例，展示如何安全、清晰地封装复合操作：

orderMapper->beginTransaction();

        try {
            // 2. 构建领域对象
            $order = new Order();
            $order->setBuyerId($data['buyer_id']);
            $order->setStatus('pending');

            // 3. 持久化主订单，获取生成ID
            $order = $this->orderMapper->save($order);

            // 4. 批量创建订单项
            foreach ($data['items'] as $itemData) {
                $item = new OrderItem();
                $item->setOrderId($order->getId());
                $item->setProductId($itemData['product_id']);
                $item->setQuantity($itemData['quantity']);
                $item->setPrice($itemData['price']);

                $this->orderItemMapper->save($item);
            }

            // 5. 提交事务
            $this->orderMapper->commit();

            return $order;
        } catch (\Throwable $e) {
            $this->orderMapper->rollback();
            throw $e;
        }
    }

    /**
     * 获取完整订单详情（单次JOIN查询，非N+1）
     */
    public function findOrderWithItems(int $orderId): ?array
    {
        return $this->orderMapper->fetchOrderWithItems($orderId);
        // SQL示例: SELECT o.*, oi.* FROM orders o JOIN order_items oi ON o.id = oi.order_id WHERE o.id = ?
    }
}

? 关键注意事项与最佳实践：

• 禁止控制器持有其他控制器：控制器是请求入口点，不是业务协调器。让 OrderController 依赖 OrderService，而非 OrderItemController。
• JOIN 查询应在 Data Mapper 中完成：如上例中 fetchOrderWithItems() 方法，由 OrderMapper 封装复杂SQL，返回结构化数组或DTO，避免在服务层拼接N+1查询。
• 事务边界由服务层定义，由基础设施层执行：OrderService::createOrder() 明确表达了“整体成功或整体失败”的业务契约，而 beginTransaction()/commit()/rollback() 应在 OrderMapper 等基础设施组件中实现（如基于PDO或ORM事务API）。
• 领域模型保持纯净：Order 类不应有 save() 方法，也不应引用 $pdo 或 OrderItemController —— 它只表达业务规则，如 public function canCancel(): bool { return $this->status === 'pending'; }。
• 可测试性优先：由于 OrderService 仅依赖接口（OrderCollection、OrderMapper），可轻松注入 Mock 对象进行单元测试，无需启动数据库。

总结而言，面对多表聚合的业务场景，真正的“复合控制器”并不存在；取而代之的是一个高内聚的服务类，它站在领域视角编排逻辑，通过清晰的接口与下层协作。这种设计不仅解决了订单这类复杂实体的CRUD问题，更奠定了系统可维护、可扩展、可演进的坚实基础。

到这里，我们也就讲完了《服务层与领域模型分离的架构实践》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！