仅涉及后端，全部目录看顶部专栏，代码、文档、接口路径在：
【Lilishop商城】记录一下B2B2C商城系统学习笔记~_清晨敲代码的博客-CSDN博客
全篇会结合业务介绍重点设计逻辑，其中重点包括接口类、业务类，具体的结合源代码分析，读起来也不复杂~
谨慎：源代码中有一些注释是错误的，有的注释意思完全相反，有的注释对不上号，我在阅读过程中就顺手更新了，并且在我不会的地方添加了新的注释，所以在读源代码过程中一定要谨慎啊！
目录
A1.会员信息
B1.M端（属于显式操作）
B2.B端（属于显式操作）
A2.店铺信息
B1.M端（属于显式操作）
B2.S端（属于显式操作）
B3.B端（属于显式操作）
A3.配送模板
B1.S端（属于显式操作）
A1.会员基本信息
由于店铺是通过会员创建的，所以这里先把会员的基本信息接口设计出来。与会员相关的收货地址、钱包等信息放到会员模块详细设计~
B1.M端（属于显式操作）
运营M端可以查看所有会员信息，也可以新增会员账号。同时还可以查看会员的订单、积分等信息，方便运营。这些小的模块的查看接口可不是在这里哦，所以就放到对应模块开发时说明了，例如积分就都放到积分模块说明。
注意哦，下面强调一下业务逻辑，在某些业务操作，例如新增用户时，不仅会创建用户信息，还会给该用进行一些额外的操作，比如增加注册积分、初始化钱包、增加注册活动优惠券等等，这些逻辑的实现如果直接放到业务代码中耦合度会增加的！所以shop项目中是使用了 Spring事件发布与监听，当用户增加完成就发布后面的事件~而事件监听类中也没有直接实现逻辑，而是封装成消息交给了RocketMQ去处理，我想这样将小业务交出去，更能提高系统性能。所以这样的逻辑就放到后面文章中解析哦~
所以会员模块的接口只有增查改删。
-
会员分页列表、通过ID获取会员信息、添加会员、修改会员基本信息、修改会员状态,开启关闭会员、根据条件查询会员总数
B2.B端（属于显式操作）
买方B端的会员信息，基本的就是注册、登录、注销、获取当前用户信息、修改用户信息、修改密码，这里先说基本的用户名登录
- 登录接口 、注销接口、注册用户、修改密码、获取当前登录用户接口、修改用户自己资料
A2.店铺信息
店铺信息可以是运营M端新增，也可以是买方B端的会员自己申请的，店铺信息包含基础信息和经营信息，店铺入驻后可以修改基本信息，而经营信息只能由运营M端申请。
PS：正常来说，店铺的营业信息应该每年检查，shop项目里面没有相关的业务逻辑。
注意：店铺S端的店主/店员也是买方B端的会员~
B1.M端（属于显式操作）
M端就包含增查改，一般来说不会有删除操作，店铺异常直接关闭即可。
跟平台店铺相关的在 li_store 表，跟店铺经营信息相关的在 li_store_detail 表里~
- 获取店铺分页列表、获取店铺详情、添加店铺、编辑店铺、审核店铺申请、关闭店铺、开启店铺、根据会员id查询店铺信息
B2.S端（属于显式操作）
店铺S端能够修改自己的店铺信息。
而且这里将店铺信息的修改拆分为了多个接口。
- 获取店铺基本信息、获取店铺退货收件地址、获取店铺发货地址、修改店铺基本信置、修改店铺库存预警数量、修改商家退货收件地址、修改商家发货地址、修改客服设置
B3.B端（属于显式操作）
买方B端会员登录之后就可以申请店铺入驻，这里也是调用了多个接口进行保存。并且如果审核不通过，还要在这里继续申请提交的，所以有获取某会员店铺信息的接口。
咱们这里只先说B端会员后台的接口，也就是只有申请入驻相关接口，B端前台显示的接口在后面说~
- 获取当前登录会员的店铺信息-入驻店铺、申请店铺第一步-填写企业信息、申请店铺第二步-填写银行信息、申请店铺第三步-填写其他信息
获取当前登录会员的店铺信息-入驻店铺接口里面包含店铺状态，所以这个接口既可以判断会员是否有入驻店铺，也可以判断现在店铺是什么状态。
A3.配送模板
配送模板完全是由店铺S端管理，发布商品（实物）时就会关联一个配送模板，然后B端会员下单商品时会根据商品关联的配送模板来判断是否配送，和配送邮费~
一个配送模板有包邮、按件计费、按重量计费，包邮的是全地区包邮，按件计费、按重量计费是可选择地区进行配置，可配置多个。
这里的地区是从行政区划里面选取的 li_region，保存时只需要保存地区id，逗号"，"隔开
PS：这样的话，如果某个模板只想要河北包邮，其余地方按件计费就需要配置两个地区~
B1.S端（属于显式操作）
- 商家运费模板列表、获取商家运费模板详情、添加商家运费模板、修改商家运费模板、删除商家运费模板
