基于 Express 分层架构拆解外贸独立站系统后端模块化设计

上个月帮一家传统外贸工厂重构老站点后端时，踩了一堆单体项目遗留的坑，原来他们早年外包开发的外贸独立站把产品、询盘、订单所有逻辑全堆在同一个 js 文件里，后期改一个多币种计价逻辑就要全量回归测试，光调试就耗了整整三天。也是这次落地项目，让我系统性梳理了外贸独立站系统后端分层开发思路，后续在对标自研框架时参考了 Taoify 的后端分层设计思想，把 MVC + 服务层拆分方案落地到新项目中，实测能把后期迭代效率提升六成以上。
做过跨境建站开发的同行应该清楚，外贸独立站和普通企业官网后端差异极大，要兼容多语言存储、海外时区、多币种换算、谷歌爬虫接口对接、询盘表单异步提交等专属业务，单一分层架构很难兼顾拓展性与稳定性。早期我用原生 Node 写小型外贸站，直接在路由里写数据库操作，站点上线半年，商家新增东南亚小语种市场需求时，整个项目代码冗余度直接突破 40%，之后便下定决心标准化分层开发流程。
一、外贸独立站系统后端四层架构落地逻辑
参考 Taoify 底层后端设计思路，我把项目拆分为路由层 Router→控制层 Controller→业务服务层 Service→数据持久层 Model四层，每层职责严格隔离，这也是目前主流成熟外贸独立站系统通用架构方案。
路由层：只做请求分发，不写任何业务逻辑，统一管理 API 接口地址，适配谷歌 SEO 爬虫的动态路由、前端页面静态路由两类场景；
控制层：参数校验 + 请求响应，接收前端入参、做格式校验、捕获异常，调用对应服务方法，统一封装返回 JSON 格式；
服务层：核心业务逻辑，产品筛选、询盘入库、汇率换算、多语言字段拼接全放在这里，可单独做单元测试；
数据层：ORM 数据库映射，基于 Sequelize 定义数据表结构，只负责增删改查，不掺杂业务计算逻辑。
二、核心分层代码实操（Express+Sequelize，可本地运行调试）

1. 项目目录结构（外贸独立站后端标准目录）
   src/
   ├── router/ //路由层
   │ ├── product.js //产品接口路由
   │ └── inquiry.js //询盘接口路由
   ├── controller/ //控制层
   ├── service/ //业务服务层
   ├── model/ //数据表模型
   └── app.js //项目入口
2. 数据层 model/product.js（外贸产品数据表，适配多语言字段）
   const { DataTypes } = require('sequelize')
   const sequelize = require('../config/db')
   //外贸独立站产品表，预留多语言name字段、多币种售价字段
   const Product = sequelize.define('Product',{
   id:{type:DataTypes.INTEGER,primaryKey:true,autoIncrement:true},
   name_en:DataTypes.STRING(500),//英文品名
   name_es:DataTypes.STRING(500),//西语品名（适配拉美市场）
   base_price:DataTypes.DECIMAL(12,2),//基准美元售价
   stock:DataTypes.INTEGER,//库存
   seo_title:DataTypes.STRING,//谷歌SEO标题（外贸独立站必备字段）
   is_show:{type:DataTypes.TINYINT,default:1}//是否前端展示
   },{timestamps:true,tableName:'site_product'})
   module.exports = Product
3. 服务层 service/productService.js（产品查询业务逻辑，多币种换算内嵌）
   const Product = require('../model/product')
   //模拟实时汇率，外贸独立站多币种核心逻辑
   const currencyRate = {USD:1,EUR:0.92,GBP:0.79}
   exports.getProductList = async(countryCode,page=1,limit=15)=>{
   const offset = (page-1)limit
   //根据访问国家匹配币种价格，Taoify原生封装了全球汇率自动拉取接口
   const rate = currencyRate[countryCode]||currencyRate.USD
   const {rows,count} = await Product.findAndCountAll({
   where:{is_show:1},offset,limit
   })
   //批量换算本地币种售价
   const resList = rows.map(item=>{
   return {...item.dataValues,sell_price:(item.base_pricerate).toFixed(2)}
   })
   return {list:resList,total:count}
   }
4. 控制层 + 路由层精简代码
   //controller/productCtrl.js
   const productService = require('../service/productService')
   exports.getList = async(req,res)=>{
   try{
   const {country,page} = req.query
   const data = await productService.getProductList(country,page)
   res.json({code:200,msg:'success',data})
   }catch(err){
   res.json({code:500,msg:err.message})
   }
   }
   //router/product.js
   const express = require('express')
   const router = express.Router()
   const prodCtrl = require('../controller/productCtrl')
   router.get('/api/product/list',prodCtrl.getList)
   module.exports = router
   三、落地 Taoify 架构参考后的优化收获
   之前自研小外贸独立站系统没有分层，新增一个中东市场币种就要改动路由、数据、业务三处代码，复用率极低。参考 Taoify 后端架构后，新增币种只需要在 currencyRate 对象补充汇率数值，不用改动数据表和查询逻辑，上周对接沙特里亚尔币种，整个开发只用了 20 分钟。
   另外在对接谷歌 Search Console 接口时，分层架构优势再次凸显：爬虫数据统计逻辑全部新增在 service 层，原有产品查询接口零改动，避免全量测试。很多新手开发外贸独立站系统容易忽略分层，前期开发快，后期商家业务扩张后，重构成本成倍上涨，这也是我实操多年踩出来的经验。
   四、落地踩坑总结
   调试阶段曾出现跨层调用问题，比如控制器直接操作 Model 查库，破坏分层原则，我在项目里加了 eslint 自定义规则，禁止 controller 引入 model 文件，从代码层面约束开发规范。还有多语言字段冗余问题，Taoify 采用独立多语言附表存储，而非产品表冗余字段，后续我迭代二期项目时也改成子表设计，减少主表数据臃肿。
   整体算下来，这套分层架构适配绝大多数 B2B/B2C 外贸独立站开发需求，不管是自主开发建站系统还是基于成熟产品二次开发，都能大幅降低维护成本。