一、搭建一个网站工程的规划和设计想法初稿 2025-07-06 21:23·霜叶做开发 摘要 我之前做.net的，按自己的流氓做法做了一套系统和框架，感觉不规范。 现在转行做Java了，跟架构师做系统，期间的经验积累，想重新搭建一个网站框架。 从几个维度考虑： 1、系统规划 2、后端工程的规划 一、系统规划 现在都前后端分离模式了，系统规划应该有两种选择： 1、前后端分离，业务应用端服务和后台管理应用端服务分离 就会有三个或四个应用部署： （1）系统前台前端 （2）系统后台前端（可以跟1整合一起） （3）系统前台应用服务 （4）系统后台应用服务 好处是后台做报表统计，导出等大数据量的应用操作的时候，就算把应用资源占用满，也不会直接影响前端业务应用端的使用 这个还有一种方案： （1）系统前台前端 （2）系统后台前端（可以跟1整合一起） （3）系统会话应用层 （4）系统前台应用服务（中台） （5）系统后台应用服务（中台） 这种部署有个优势，就是后续业务扩展了，（4）和（5）可以不断的扩节点做支持 2、前台和后台一体 这种方式，甚至前后端的页面也整合到一起，一个简单的部署工程 优点：适合小网站的应用，不然给客户做一个系统，给人搭建四个应用甚至更多，杀鸡牛刀。 不过最好的方式是前后端可分可合 我想到的方案： 1、用redis管理会话 2、业务应用端应用服务和后台管理应用服务是同一套代码，接口地址路径有区别，到时分开部署 3、使用minio或其他存储管理附件。 二、后端工程的规划 1、通用类： （1）通用工具类可以用hutool，不必重复造轮子。这样的好处，大家都用相同的工具类，代码参考和引用（CV大法），就不需要二次改动，直接用即可 （2）有些方法，如hutool没有支持的，可以用通用工具类扩展实现。但原则上这个类里面的代码逻辑，不能跟业务有任何关联。其他都能使用。 比如： 如果在这个工具类里面约定一个枚举： 车辆状态： 正常 维修 遗失 损坏 报废 这个枚举定义跟业务有关，在这个类里面定义，就不合适了。 辅助工具类： 如poi实现Excel的导入和导出，需要引用poi的jar，单独建一个类，后需要的工程就引用，不需要的就避免不必要的全家桶 2、系统通用类 系统不可能只有一个，比如会用用户管理系统，车辆管理系统，考试管理系统等等，每个系统都会有一些通用的约定，这些可以放在这个系统通用类里面。后续系统开发可以直接引用。 3、框架基础类 （1）实体基础类 （2）业务操作基础类（待定） 4、数据库实体类 各个业务的表实体和枚举字典信息 这种实体类单独存放，跟数据库访问操作无关，后续其他业务系统需要用的时候，可以考虑直接引用 5、业务实体类 6、业务数据库操作类 考虑是否支持多数据库类型，比如同时支持mysql、oracle。 之前的系统，甲粑粑有Q，都是基于oracle实现，后续市场变化了，想把原先做的系统包装往外扩展，发现要改造，支持mysql，无形中增加了开发成本。所以，最好考虑能支持多种数据库 7、业务服务层 实现调用各个业务数据库操作类，或者外部接口等，实现业务逻辑 8、控制层 每个业务单独一个控制层类 9、外部服务调用层 比如调用微信、调用支付宝等服务 有些服务是需要引用第三方的jar包的，考虑放在这个业务层 后续如果觉得引入到工程会污染，可以考虑把这个服务层抽离出来做一个独立服务，通过http调用 10、主应用服务 启动、加载配置等 初步想法，后续每个点都需要考虑和细化。 所以，说是初稿，后续参考看看若依框架是怎么规划的，学习别人是怎么规划的。 对了，还漏了interface，接口层设计 分组 类 说明 工具 com.xx.ba.tool 通用工具类 工具 com.xx.ba.poi excel的支持 基类 com.xx.core.common 各个系统的通用类 基类 com.xx.core.table 数据库实体相关信息 基类 com.xx.core.dto 各种实体的数组（这里没有操作数据库层） 基类 com.xx.core.dal 数据库操作层（规划可以支持多数据库）-待设计 扩展应用类 com.xx.ex.helper 扩展的调用类 业务实体类 com.xx.app.user.table 业务实体类 com.xx.app.user.dto 业务实体类 com.xx.app.user.dal 业务实体类 com.xx.app.user.manager 业务实体类 com.xx.app.user.svc 业务实体类 com.xx.app.user.ctrl 主应用 com.xx.app.main