企业官网建设流程全解析

• 文档
• 教程
• 后端

Lottery 分布式抽奖系统在完成核心抽奖服务（Lottery 工程）之后，还需要一套面向运营人员的 B 端管理系统，用来配置活动、查询数据、审核状态。本篇基于「第01节：UI工程搭建」展开，系统讲解 Lottery-ERP 运营后台的选型思路、DDD 分层工程结构与 layui 前端资源的整合方式，读完你将掌握"后端 Java 团队在没有专职前端的情况下，如何快速搭建一套内部运营后台"的完整方案。

一、为什么需要一个独立的运营后台

在整个营销体系中，抽奖系统只是众多微服务之一，而支撑运营人员日常工作的管理端必不可少。参考 Lottery 抽奖系统整体介绍 中对六个工程的拆分，其中Lottery-ERP 就是 B 端运营系统，用于满足运营人员对活动的查询、配置、修改、审核等操作，它与面向 C 端用户的 H5 抽奖页面（Lottery-Front）职责完全不同：

• Lottery：分布式部署的抽奖服务，提供抽奖业务领域功能，以 RPC 方式对外提供服务；
• Lottery-ERP：B 端运营系统，运营人员在这里管理活动与查看数据；
• Lottery-Front：C 端用户系统，vue H5 大转盘抽奖界面。

运营后台面向的是内部运营人员，用户量小、功能集中、迭代以内部需求为主，因此在技术选型上与 C 端系统有本质差异。

二、UI 方案选型：三套方案对比与取舍

在考虑运营后台搭建时，第一个要解决的问题是：UI 方案怎么选。如果公司里有前端人员来开发后台运营页面，基本会使用 vue、react、angular 等前端框架；但如果没有专职前端，而是需要后端 Java 人员来开发，就必须考虑迭代和维护成本——并不是所有后端研发都需要去学习 vue 这类前端开发语言。

当时汇总并对比了三套运营后台 UI 方案：

最终选择layui 作为运营后台的搭建框架，核心原因有两点：

1. 上手成本低：layui 是基于 jQuery 的经典组件库，页面结构、写法与传统的服务端渲染页面接近，Java 后端研发几乎不需要额外学习前端工程化体系就能直接上手；
2. 够用且稳定：虽然 layui 已经停止更新维护，但对于内部运营后台这类以表单、表格、查询为主的页面来说，日常使用完全够用。

同时原文档也给出了明确的规划：后续开发 C 端抽奖页面（大转盘 H5）时再使用 vue 语言，这样一套系统里两种前端方式都能覆盖到；如果对 vue 很感兴趣，也可以直接使用 vue 的方式搭建运营后台页面，本方案并非唯一答案。

三、工程整体结构：DDD 分层 + layui 的组合

确定 UI 方案后，运营后台工程采用DDD 架构分层结构 + layui的组合方式来搭建。

为什么在运营后台也要坚持 DDD 结构？原因在于：这是 DDD 在没有 RPC 引入时的紧凑结构模型，可以非常直观地体现"Application 应用层定义接口 → Domain 领域层做实现 → 最终交给 interfaces 接口层使用"的完整调用链。运营后台的代码规模比核心抽奖服务小，用它来演示和巩固 DDD 分层思想是非常合适的场景。

下图展示了 Lottery-ERP 工程的整体目录结构（图片位于 docs/.vuepress/public/images/article/project/lottery/Part-3/1-01.png）：

从图中可以看到整个工程分为两大部分：

1. 按照 DDD 分层的运营后台服务端（Java 部分）

项目根目录为Lottery-ERP，Java 代码位于src/main/java下的cn.itedus.lottery.erp包，包含四个核心模块：

• application（应用层）：负责协调领域逻辑、封装用例流程，定义对外的应用服务接口；
• domain（领域层）：如domain.activity活动领域模块，承载核心业务规则与领域服务实现；
• infrastructure（基础设施层）：提供通用技术能力、实现数据持久化等支撑性内容；
• interfaces（接口层）：负责对外提供服务接口的定义与暴露。

入口类LotteryErpApplication是 Spring Boot 项目的启动类。

2. 运营后台 UI（Web 端）

前端代码位于src/main/webapp路径下，包含的模块有：

• api：前端接口调用定义；
• css：样式文件；
• images：资源图片；
• js：前端脚本；
• lib：依赖库（layui 等组件库存放处）；
• lottery：业务相关代码；
• page：页面组件；
• index.html：前端入口页面。

这种"Java 分层 + webapp 静态资源"并存的结构，正是"非前后端分离"模式在内部运营后台中的典型应用。

四、DDD 分层中各层的职责边界

要真正理解上面的工程结构，需要先明确 DDD 四层架构中各层的职责。在 Part-2 第02节：搭建DDD四层架构 中对分层原则做了详细说明，这里结合运营后台工程归纳如下：

• 应用层（application）：用来表述应用和用户行为，负责服务的组合、编排和转发，负责处理业务用例的执行顺序以及结果的拼装。在运营后台中，页面请求先到达应用层定义的服务接口；
• 领域层（domain）：领域服务位于领域层，为完成领域中跨实体或值对象的操作转换而封装服务。领域服务封装了核心的业务逻辑，实体自身的行为在实体类内部实现，向上封装成领域服务暴露；为隐藏领域层业务逻辑实现，所有领域方法和服务均须通过领域服务对外暴露；
• 基础设施层（infrastructure）：提供数据持久化、缓存、文件等通用技术能力；
• 接口层（interfaces）：对外暴露 HTTP 接口，接收前端请求并返回响应。

这样"Application 定义接口、Domain 实现业务、Infrastructure 提供支撑、Interfaces 对外暴露"的调用链，与 MVC 结构相比，新增功能扩展时结构依旧清晰——只要结构清晰、地基打得好，后续盖房子（加功能）就非常容易，这也是在运营后台中坚持 DDD 结构的重要价值。

五、UI 直接放入工程：非前后端分离的务实选择

值得特别说明的是，这里的 UI 部分不是前后端分离的，而是直接放到工程中（src/main/webapp），这算是一种比较"古老"的实现方式。

但从实际业务场景看，这种选择非常合适：

• 运营后台通常只是内部运营人员使用，不面向外部 C 端用户，对页面交互复杂度、并发量要求都不高；
• 前后端代码放在同一工程中，部署、版本管理、联调都更简单，Java 研发人员可以一条链路完成从页面到接口的全部开发；
• 一般部署 2 台应用实例做个互备就足够了，不需要复杂的前端 CDN、网关等基础设施。

六、工程搭建之后的业务延伸

运营后台的基础工程结构搭建完成后，后续章节围绕它逐步填充业务功能，形成了完整的 Part-3 系列（参见 Part-3 章节目录）：

• 第02节：活动列表数据展示：在运营后台中提供活动列表查询。因为活动的配置在单库单表中，直接提供查询服务即可；同时要注意，给运营后台查询的数据通常直接使用LIMIT x,y分页即可，而如果是 C 端用户展示列表数据，则应使用> id LIMIT x的方式，两者有本质区别；
• 第03节：用户抽奖数据展示：继续填充用户抽奖数据的可视化展示能力。

而在 C 端侧，Part-4 第02节：vue H5 大转盘抽奖 则使用 vue 语言开发面向用户的抽奖页面，与运营后台的 layui 形成"B 端 layui + C 端 vue"的双前端格局，完整覆盖了两类不同场景的技术栈实践。

七、小结

本节的要点可以归纳为四句话：

1. 选型看场景：没有专职前端时，layui 这类基于 jQuery 的组件库是 Java 后端搭建内部运营后台的低成本选择；有前端资源或对扩展性要求高时，再考虑 vue/react 方案；
2. 结构坚持 DDD：运营后台虽然规模小，但正好用紧凑的"Application 定义接口、Domain 实现、interfaces 使用"结构来落地 DDD 分层思想，为后续功能扩展打好地基；
3. 非前后端分离够用：UI 直接放入工程的src/main/webapp，配合api/css/images/js/lib/lottery/page的目录划分，让 Java 研发能独立完成运营页面的开发与维护；
4. 部署从简：内部运营后台通常部署 2 台应用实例互备即可，不需要为它引入复杂的前端工程体系。

后续章节将在这一工程基础上，逐步开发活动列表查询、用户抽奖数据展示等运营功能，把 DDD 分层与 layui 的组合持续落到实处。

• 文档
• 教程
• 后端