企业官网建设流程全解析

• 文档
• 教程
• 后端

本文是 Lottery 分布式抽奖系统「运营后台（Part-3）」系列的第 02 节实战指南，讲解如何在 DDD 四层架构下为 ERP 运营后台提供活动列表查询能力：在活动领域的"活动部署子领域"新增查询服务、定义分页参数、通过 RPC 将接口暴露给 ERP 工程并完成页面数据可视化展示。读完本文，你将掌握在 Lottery 项目中新增一个"查询类"领域功能的标准落地姿势——包括 DDD 分层扩展、分页信息对象设计、C 端/B 端分页 SQL 差异，以及如何复用既有 RPC 调用链路打通 ERP 页面数据。

一、本节开发目标与前置背景

在第 01 节：UI 工程搭建中，Lottery-ERP 运营后台的基础工程结构已经搭建完成（采用 DDD 分层 + layui 前端方案）。本节开始往工程里填充第一个真实功能——活动列表查询。

围绕这个功能，整个开发日志可以拆解为四个关键动作：

1. 领域层扩展：活动配置存放在"单库单表"的activity表中，因此直接提供查询服务即可，无需跨库聚合；
2. 新增分层包结构：Lottery 主工程需要新增接口层、应用层的分包（vo、req、res 分别归类），避免对象混放难以维护；
3. 定义分页参数：对数据库使用普通的LIMIT分页查询，并额外定义 Page 分页信息对象，方便 ERP 按页拉取数据；
4. 打通 RPC + 可视化：接口开发完成后，通过 RPC 方式供 ERP 工程调用，在运营后台页面完成列表数据展示。

注意：这里的"运营后台查询"对应的是 B 端场景，直接使用LIMIT x,y即可；如果将来为 C 端用户展示列表数据，则不能这样分页，而要改用WHERE id > ? LIMIT x的游标式分页（详见下文第四部分）。

二、为什么新增功能要落在"活动部署子领域"

在 DDD 分层结构中，新增一个查询功能并不是"哪里方便放哪里"，而是要找对领域归属。本节功能落在活动领域（activity）中的"活动部署子领域（deploy）"，原因很直接：活动部署子领域已经承担了活动的配置、修改、状态流转，自然也应该提供活动的列表查询。

• 在活动领域层中继续添加活动相关服务，比硬塞到别的领域更符合职责边界。对照 MVC 结构可以发现，只要领域结构清晰、地基打好，扩展一个新功能是非常容易的，这也是 DDD 相比传统分层在"可扩展性"上的直观体现。
• 这里有一个技术实现要点：给 ERP 的查询结果必须包含分页信息——即数据列表与总条数；具体如何分页、每页多少条，交给 ERP 自己配置和实现。领域服务只负责接收请求参数并返回结果数据，不掺入任何页面层的分页策略。

关于活动领域整体设计的更多背景（活动创建、状态流转、仓储接口下沉到基础层等），可参考 第 08 节：活动领域的配置与状态。从源码结构看，domain领域层定义仓储接口、infrastructure基础层实现仓储接口，查询列表走的正是这条"领域服务 → 仓储接口 → 仓储实现"的调用链。

三、应用层新增"活动部署处理"子模块

查询功能虽然简单，但为了让 vo、req、res 不混在一起，Lottery 主工程在**应用层（application）**也新增了process/deploy子模块来承接领域服务，接口为IActivityDeployProcess。

从整体分层依赖关系看（详见 Part-2 第 03 节：跑通广播模式 RPC 过程调用）：

这样一个"接口层定义 RPC 接口 → 应用层编排 → 领域层实现业务 → 基础层访问数据"的链路，可以确保新增的查询接口不会把请求/响应对象散落到各层，后续同类功能照葫芦画瓢即可。

四、分页设计：B 端 LIMIT 与 C 端游标分页的取舍

活动列表查询对数据库只是普通的LIMIT分页，因此本节额外定义 Page 分页信息，让查询更规范。这是本节最值得沉淀的一个"技术细节"：

• B 端（运营后台）列表：直接使用LIMIT x,y（如LIMIT 0, 10）即可。运营人员手动翻页、数据总量有限，偏移量分页足够且实现最简单；
• C 端（用户端）列表：不能使用LIMIT x,y，而要使用WHERE id > ? LIMIT x的游标分页。原因在于 C 端列表往往伴随大量并发请求与持续写入，LIMIT x,y在大偏移量下会产生深分页扫描，性能急剧下降，且翻页过程中新增数据会导致页码漂移。

MySQL 的LIMIT分页 SQL 本质形态如下（offset为偏移量、size为每页条数）：

-- B 端运营后台：偏移量分页 SELECT activity_id, activity_name, begin_date_time, end_date_time, stock_count FROM activity ORDER BY create_time DESC LIMIT #{offset}, #{size};

-- C 端用户列表（参考写法）：游标分页 SELECT activity_id, activity_name, begin_date_time, end_date_time, stock_count FROM activity WHERE id > #{lastId} ORDER BY id LIMIT #{size};

分页信息对象（Page）的设计要点：

• 请求侧：接收page（页码）与rows（每页条数）两个入参，由 ERP 自行配置每页多少条；
• 响应侧：返回list（本页数据）与count（总条数），供前端渲染分页器；
• 领域服务只接收请求、返回结果，分页策略完全解耦在调用方。

五、RPC 接口暴露与 ERP 侧消费

Lottery 主工程的接口层（interfaces）在完成领域、应用层开发后，需要把查询接口以RPC 方式暴露出来，供 Lottery-ERP 工程消费。RPC 的广播模式调用、@Reference直连配置等在 Part-2 第 03 节 中已有完整跑通过程，本节直接复用这套链路。

ERP 侧（Lottery-ERP 工程）的分工如下：

• 服务层：定义活动查询接口IActivityService及其实现ActivityServiceImpl，内部通过 RPC 调用 Lottery 主工程暴露的查询服务；
• Web 层：提供ActivityController及queryActivityListPage接口方法，响应前端页面的 HTTP 请求，把分页结果返回给 layui 表格组件渲染。

六、运营后台页面效果与验证

完成接口开发并打通 RPC 后，在运营后台"活动中心 → 活动列表"页面即可看到分页形式的列表数据，包含活动 ID、活动名称、开始/结束时间、库存等数据项，由 ERP 页面负责分页器与表格渲染。

验证步骤建议：

1. 在activity表（建表语句见 Part-2 第 03 节 中的activity活动表结构）中插入多条活动数据，覆盖不同状态（1编辑、2提审、4通过、5运行等）；
2. 启动 Lottery 主工程（提供 RPC 服务）与 Lottery-ERP 工程；
3. 访问运营后台活动列表页面，翻页查看列表与总条数是否正确，核对每页条数与LIMIT分页结果一致。

七、本节小结与后续衔接

本节完成的功能虽小，却完整演示了在 Lottery 项目中"新增一个领域查询服务"的标准动作：

• 领域归属：查询功能落在活动部署子领域，保持 DDD 职责边界清晰；
• 分层扩展：应用层新增process/deploy子模块，请求/响应对象按 vo、req、res 分包管理；
• 分页规范：B 端用LIMIT x,y，C 端用> id LIMIT x，Page 对象只承载"数据 + 总条数"；
• 链路打通：领域服务 → 应用层编排 → RPC 暴露 → ERP 消费 → layui 页面渲染，全链路复用既有基础设施。

下一节将延续"运营后台"主题，进一步实现用户抽奖数据展示，把抽奖业务数据同样可视化到运营平台；整个 Part-3 运营后台在整套 Lottery 系统（Lottery 服务、Lottery-ERP、Lottery-API、Lottery-Front、DB-Router、Lottery-Test 六大工程）中承担 B 端运营配置与数据查看的职责，项目整体背景可参考 Lottery 抽奖系统介绍。

• 文档
• 教程
• 后端