【Lilishop商城】No2-1.确定项目结构和数据结构（用户、商品、订单、促销等模块）

仅涉及后端，全部目录看顶部专栏，代码、文档、接口路径在：

【Lilishop商城】记录一下B2B2C商城系统学习笔记~_清晨敲代码的博客-CSDN博客

---

首先先看一下项目的开发架构，都需要哪些技术，都按照哪些规范，都哪些模块涉及哪些架构。然后看一下数据库间的关联，确定数据结构。

目录

A1.项目结构

B1.代码架构

C1.framework：架构/ 核心代码

C2.common-api：基础API

C3.buyer-api :买家API、manager-api：管理端API、seller-api：店铺API

C4.consumer 消费者，消费mq，定时任务延时任务

C5.xxl-job：定时器

A2.数据结构

B1.运营用户模块

B2.运营的系统配置

B3.店铺的设置

B4.店铺店员

B5.会员信息

B6.商品

B7.订单

B8.促销

B9.消息

遇到的坎儿：

1.用户认证授权逻辑

---

A1.项目结构

项目README里面写清楚了后台技术选型如下

开发规范和架构文档也都给出来了，也挺详细的

后端开发规范 · GitBook

接下来我就重点根据代码写一下代码架构，先搞清楚里面的逻辑，这样才好理解最终的数据结构~

B1.代码架构

官方文档中代码架构如下，就是介绍了主目录

framework：架构/ 核心代码

common-api：基础API

buyer-api :买家API

manager-api：管理端API

seller-api：店铺API

consumer 消费者，消费mq，定时任务延时任务

xxl-job：定时器

admin：springboot-admin 运行监控，管理和监控SpringBoot应用程序

config：整个项目的config包下配置文件，优先级最高

DB：数据库文件

C1.framework：架构/ 核心代码

这里重点就是 module 包，里面按照模块划分了三端的所有的业务逻辑。

​

C2.common-api：基础API

是基础公共接口的项目，不是依赖包，是单独的项目

​

C3.buyer-api :买家API、manager-api：管理端API、seller-api：店铺API

这三个端的后端接口都是一样的

​

C4.consumer 消费者，消费mq，定时任务延时任务

根据后续业务进行

C5.xxl-job：定时器

jar包运行

A2.数据结构

先看主流程关联的内容，其余的后面慢慢填补~

1.白色底纹：两表的关联表

2.绿色底纹：业务表

3.蓝色底纹：重复的表

B1.运营用户模块

这一块没啥好说的，就是普遍的 RBAC 结构。

说明一点，这里一个管理用户只对应一个部门~

 

B2.运营的系统配置

1.配置表里面是一些系统配置，有一个字符类型的唯一标识，和对应json类型的value

2.行政区划表是按照高德地图的规范来的，可以看：行政区域查询-API文档-开发指南-Web服务 API | 高德地图API

3.物流公司里面有个电子面单表单，可暂时忽略，系统中也没说明；

B3.店铺的设置

店铺这儿没啥好说的，就是店铺会关联一个店主（就是一个会员）

 

B4.店铺店员

会员与店铺之间的关联，就靠店员表，一个会员只能加入一个店铺，无论他是店主还是店员。

剩下的角色、部门、菜单就与运营用户模块一样了

B5.会员信息

这里需要注意一点，用户积分直接存到了会员表里面，会在新表里记录积分更改历史；

而余额信息是单独存的表，因为涉及到资金冻结等操作，同时也会在新表里记录余额更改历史；

 

B6.商品

商品这里有挺多东西的，要注意分清哪些是运营管理的，哪些是店铺使用的；

最重要的就是商品表和商品sku表；

说明一下，商品分为虚拟的和实物的，虚拟的不需要物流；

实物商品又分为批发的和零售的，这一块逻辑要分清楚哦，批发的sku部分属性是按照批发类型走的

B7.订单

订单这里三类表：交易表、订单表、子订单表;

一次付款生成一份交易单：包括本次付款的所有商品；

一份交易单根据店铺分为多个订单：每份订单包含本次交易下的一个店铺下的所有商品；

一份订单根据商品分为多个子订单：每份子订单包含当前订单下的一个商品；

售后是针对与一个子订单和商品sku的，不是针对于订单的；

 投诉和评价是针对于商品sku的，不是针对于订单、子订单的哦

B8.促销

由于促销大部分都是围绕着商品来的，每类活动也大多相似，所以可以将活动的相似属性设置为一致的。我看后端代码结构也是这样的，会抽象出活动相似的东西，来实现~

这里要清楚每类促销的属性，否则就很容易缺少字段或者缺少关联，后期补充很麻烦的~

积分商品：一个活动对应一个商品                                （运营发布）
优惠券    ：一个活动对应多个商品/多个商品分类        （运营、店铺发布）
券活动    ：一个活动对应多个优惠券                           （运营、店铺发布）
满额活动：一个活动对应多个商品                                （店铺发布）
拼团        ：一个活动对应多个商品                                （店铺发布）
秒杀        ：一个活动对应多个商品                                （系统发布、店铺添加商品）
砍价        ：一个活动对应一个商品                                （运营发布）

所以根据上面可以再添加一个促销活动商品表，来记录某个活动的关联商品；

B9.消息

系统消息模板就是类似系统发布的，例如商品审核不通过、订单取消；

消息就是指运营发布的站内信，指定发给某些会员或者某些店铺；

原来我看的的消息机构，就一张表，里面包含接收人和发送人，这样的话单独查询的系统发布的站内信时就需要转化一下。分为两张表后，可以先保存发送信息，然后通过rocketMQ发送接受的信息~这样更清晰

---

 

遇到的坎儿：

1.用户认证授权逻辑

一开始没搞清楚，安全认证这里他用的是 WebSecurityConfigurerAdapter、BasicAuthenticationFilter，BasicAuthenticationFilter之前没用过，网上搜也没看到相关信息，打断点也没找到，由于这个类也是security的，于是就把WebSecurityConfigurerAdapter的又了解了一遍深入理解 WebSecurityConfigurerAdapter【源码篇】__江南一点雨的博客-CSDN博客