public class GoodsOperationDTO implements Serializable {

    //与其他表无关联的，基本数据类型的业务基本信息；
    @ApiModelProperty(hidden = true)
    private String goodsId;

    @ApiModelProperty(value = "商品名称", required = true)
    @NotEmpty(message = "商品名称不能为空")
    @Length(max = 50, message = "商品名称不能超过50个字符")
    private String goodsName;
。。。
    //与其他表关联的业务基本信息，可理解为外键；
    @ApiModelProperty(value = "商品分类path，逗号隔开")
    private String categoryPath;

    @ApiModelProperty(value = "店铺分类id，逗号隔开", required = true)
    @Size(max = 200, message = "选择了太多店铺分类")
    private String storeCategoryPath;
。。。
    //引用类型的业务基本信息；
    @ApiModelProperty(value = "商品参数")
    private List<GoodsParamsDTO> goodsParamsDTOList;

    @ApiModelProperty(value = "sku列表，因为无法匹配pojo类，所以是用map接收")
    @Valid
    private List<Map<String, Object>> skuList;

。。。
    //业务校验/判断的字段；
    @ApiModelProperty(value = "是否有规格", hidden = true)
    private String haveSpec;

    @ApiModelProperty(value = "是否重新生成sku数据")
    private Boolean regeneratorSkuFlag = true;
。。。

}

C2.业务逻辑

核心业务逻辑是说该接口主要的业务操作，不结合其他复用情况或者业务情况的！！！

而实际操作业务逻辑是结合了复用代码和其他业务情况的操作，所以实际操作肯定会有一些判断或其他代码逻辑。

所以核心业务逻辑主要是说明该接口具体是做了什么，是针对前端理解、设计理解、后端理解而言的，而实际操作业务逻辑是说明该接口怎么用业务逻辑实现，仅针对后端理解。

D1.核心业务逻辑

根据商品DTO生成商品和商品skulist的基本信息，保存商品和skulist，然后生成并保存其对应的子表信息；
添加商品成功后，如果商品是审核通过且上架状态，则需要根据商品信息生成es商品sku索引列表，进行分词存储后，保存es商品sku索引列表。

D2.实际操作业务逻辑

接下来我们就需要针对核心业务逻辑进行进一步实现了！

在介绍业务逻辑时，会涉及到一些其他代码结构，有需要说明的就用绿色底纹标注，然后在后面的代码逻辑里面详细介绍。

GoodsStoreController#save：

拿到入参DTO，调用service方法添加商品；
返回ResultUtil.success()；有异常则进入异常拦截返回异常；

GoodsServiceImpl#addGoods：

构造器new一个商品PO对象，并将DTO里的基本信息set给商品PO，其中可以校验DTO信息是否有效；
根据业务，检查并set商品信息：1.判断商品类型，是虚拟的还是实物的，进而配置配送模板；2.判断商品id是否存在，是新增还是修改；3.判断商品是否需要审核；4.判断当前用户是否为店铺，并设置店铺信息；
将商品图册列表中第一个图片set为商品默认图片，并拿到set缩略图等；
set商品参数，参数转为JSON类型保存；
save商品信息;【到这个步骤商品基本信息已设置完毕】；
判断商品DTO里是否有 GoodsGalleryList 商品图册信息，save商品图册信息；【子表关联】
判断商品DTO里是否有 skuList 商品规格信息，for循环使用构造器new一个商品skuPO对象，并将商品基本信息set给商品skuPO，然后将商品规格信息 set 给商品skuPO；
根据销售模式渲染，如果是批发模式需要再渲染sku信息和save批发信息；【子表关联】
set图册列表中第一个为商品图册默认图片，并拿到set缩略图等；
循环商品sku，将规格json里面图片列表的第一个set为商品sku默认图片，并拿到set缩略图等；
批量save商品sku信息；【子表关联】
修改商品库存为商品sku的库存总和；
如果商品是已审核通过且上架状态的，则发送生成es商品sku索引的rocketMq消息，只需要传递商品id就可以。
MQ执行时，通过商品ID拿到商品信息和商品skulist信息，然后根据这两个信息构建出es商品sku索引EsGoodsIndex列表信息，将根据列表里面的商品参数和商品名称进行分词存储后，save es商品sku索引；

下面就贴一下service的添加商品方法的截图，具体的代码逻辑看下面的代码逻辑分析~~

C3.代码逻辑

D1.构造器new一个商品PO对象

首先，我们知道商品PO表里面都是商品的基本信息，所以可以直接通过PO类的构造器进行赋值，由于商品DTO表较为复杂、使用DTO对象构造PO对象前需要校验、有其他业务也会复用到DTO对象构造PO对象，所以就手动给PO类中添加此类型的构造方法~

@EqualsAndHashCode(callSuper = true)
@Data
@TableName("li_goods")
@ApiModel(value = "商品")
public class Goods extends BaseEntity {
。。。
    public Goods(GoodsOperationDTO goodsOperationDTO) {
        //基本信息赋值
        this.goodsName = goodsOperationDTO.getGoodsName();
        this.categoryPath = goodsOperationDTO.getCategoryPath();
        this.storeCategoryPath = goodsOperationDTO.getStoreCategoryPath();
        this.brandId = goodsOperationDTO.getBrandId();
        this.templateId = goodsOperationDTO.getTemplateId();
        this.recommend = goodsOperationDTO.getRecommend();
        this.sellingPoint = goodsOperationDTO.getSellingPoint();
        this.salesModel = goodsOperationDTO.getSalesModel();
        this.goodsUnit = goodsOperationDTO.getGoodsUnit();
        this.intro = goodsOperationDTO.getIntro();
        this.mobileIntro = goodsOperationDTO.getMobileIntro();
        this.goodsVideo = goodsOperationDTO.getGoodsVideo();
        this.price = goodsOperationDTO.getPrice();
        if (goodsOperationDTO.getGoodsParamsDTOList() != null && goodsOperationDTO.getGoodsParamsDTOList().isEmpty()) {
            this.params = JSONUtil.toJsonStr(goodsOperationDTO.getGoodsParamsDTOList());
        }
        //判断是否立即上架
        this.marketEnable = Boolean.TRUE.equals(goodsOperationDTO.getRelease()) ? GoodsStatusEnum.UPPER.name() : GoodsStatusEnum.DOWN.name();
        this.goodsType = goodsOperationDTO.getGoodsType();
        //商品评分，初始100
        this.grade = 100D;

        //循环sku，判定sku是否有效，根据销售模式、商品类型
        /*
            sn 、quantity：是任何销售模式下、任何商品类型下都有的
            price、cost：是零售销售模式下、任何商品类型下有的
            weight：是任何销售模式下、商品实物类型下有的
         */
        for (Map<String, Object> sku : goodsOperationDTO.getSkuList()) {
            //判定参数不能为空
            if (!sku.containsKey("sn") || sku.get("sn") == null) {
                throw new ServiceException(ResultCode.GOODS_SKU_SN_ERROR);
            }
            if (!sku.containsKey("quantity") || StringUtil.isEmpty(sku.get("quantity").toString()) || Convert.toInt(sku.get("quantity").toString()) < 0) {
                throw new ServiceException(ResultCode.GOODS_SKU_QUANTITY_ERROR);
            }
            //判断参数是否有效，并且是非批发销售模式下的
            if ((!sku.containsKey("price") || StringUtil.isEmpty(sku.get("price").toString()) || Convert.toDouble(sku.get("price")) <= 0)
                    //非批发销售模式。添加此判断是因为成本和价格仅针对零售销售模式而言，但是前端有可能会先填写过零售模式的规格后又修改为批发模式，就会导致price参数不对，如果是批发销售模式此参数就无所谓了
                    && !goodsOperationDTO.getSalesModel().equals(GoodsSalesModeEnum.WHOLESALE.name())) {
                throw new ServiceException(ResultCode.GOODS_SKU_PRICE_ERROR);
            }
            if ((!sku.containsKey("cost") || StringUtil.isEmpty(sku.get("cost").toString()) || Convert.toDouble(sku.get("cost")) <= 0)
                    //非批发销售模式
                    && !goodsOperationDTO.getSalesModel().equals(GoodsSalesModeEnum.WHOLESALE.name())) {
                throw new ServiceException(ResultCode.GOODS_SKU_COST_ERROR);
            }
            //虚拟商品没有重量字段
            if (this.goodsType.equals(GoodsTypeEnum.PHYSICAL_GOODS.name()) &&
                    (!sku.containsKey("weight") || sku.containsKey("weight") && (StringUtil.isEmpty(sku.get("weight").toString()) || Convert.toDouble(sku.get("weight").toString()) < 0))) {
                throw new ServiceException(ResultCode.GOODS_SKU_WEIGHT_ERROR);
            }
            sku.values().forEach(i -> {
                if (CharSequenceUtil.isBlank(i.toString())) {
                    throw new ServiceException(ResultCode.MUST_HAVE_GOODS_SKU_VALUE);
                }
            });
        }
    }
。。。
}

D2.根据业务，检查并set商品信息

仅仅靠构造器new的PO对象不是最完全的，可能会有特殊业务需要再次修改，所以添加一个专门处理特殊业务的防范来解决。

例如，这里就需要添加一下的业务：

//cn.lili.modules.goods.serviceimpl.GoodsServiceImpl
    /**
     * 根据业务，检查商品信息
     * 如果商品是虚拟商品则无需配置配送模板
     * 如果商品是实物商品需要配置配送模板
     * 判断商品id是否存在。修改商品时会复用此方法
     * 判断商品是否需要审核。系统配置里面设置的
     * 判断当前用户是否为店铺，并设置店铺信息
     *
     * @param goods 商品
     */
    private void checkGoods(Goods goods) {
        //判断商品类型，是虚拟的还是实物的
        switch (goods.getGoodsType()) {
            case "PHYSICAL_GOODS":
                if ("0".equals(goods.getTemplateId())) {
                    throw new ServiceException(ResultCode.PHYSICAL_GOODS_NEED_TEMP);
                }
                break;
            case "VIRTUAL_GOODS":
                if (!"0".equals(goods.getTemplateId())) {
                    goods.setTemplateId("0");
                }
                break;
            default:
                throw new ServiceException(ResultCode.GOODS_TYPE_ERROR);
        }
        //检查商品是否存在--修改商品时使用
        if (goods.getId() != null) {
            this.checkExist(goods.getId());
        } else {
            //评论次数
            goods.setCommentNum(0);
            //购买次数
            goods.setBuyCount(0);
            //购买次数
            goods.setQuantity(0);
            //商品评分
            goods.setGrade(100.0);
        }

        //获取商品系统配置决定是否审核
        Setting setting = settingService.get(SettingEnum.GOODS_SETTING.name());
        GoodsSetting goodsSetting = JSONUtil.toBean(setting.getSettingValue(), GoodsSetting.class);
        //set审核状态
        goods.setAuthFlag(Boolean.TRUE.equals(goodsSetting.getGoodsCheck()) ? GoodsAuthEnum.TOBEAUDITED.name() : GoodsAuthEnum.PASS.name());
        //判断当前用户是否为店铺
        if (Objects.requireNonNull(UserContext.getCurrentUser()).getRole().equals(UserEnums.STORE)) {
            StoreVO storeDetail = this.storeService.getStoreDetail();
            if (storeDetail.getSelfOperated() != null) {
                goods.setSelfOperated(storeDetail.getSelfOperated());
            }
            goods.setStoreId(storeDetail.getId());
            goods.setStoreName(storeDetail.getStoreName());
            goods.setSelfOperated(storeDetail.getSelfOperated());
        } else {
            throw new ServiceException(ResultCode.STORE_NOT_LOGIN_ERROR);
        }
    }

D3.拿到set缩略图【商品缩略图统一在这里说明】

商品和商品sku都有自己单独的默认图，以及默认图的缩略图、小图。

此默认图和图册列表是有区别的，一般会是由图册列表里的第一张图作为默认图。

商品默认图，可用于S端商品列表的列表中显示的图片；
商品sku默认图，可用于B端搜索商品时列表中展示的图片；
商品图册，暂时还不知道用在哪里，但是商品sku也就是商品规格的图片默认是拿取的商品图册的【S端新增/修改商品时】，但是sku图册是可以修改的；
商品sku图册，可用于B端打开商品详情时，左侧显示的商品图片；

用户在新增/修改商品时，会上传图片，然后拿到图片存储url。【上传方法见cn.lili.controller.common.UploadController#upload，是上传到阿里云的OSS上】

然后新增商品时就会根据上方原图url，拿到其缩略图等信息，由于可以复用，所以抽象成一个方法。

商品sku的默认图也是如此，这里就不复述了

D4.set商品参数

这个就是记录一下，商品参数是作为 JSON 存储的，后续会在获取商品信息等功能中转成商品参数的类型，没有复杂的业务。重点就是前端传值格式一定要和后端对应的pojo对象类型一致~~否则json转格式转不成功的！

D5.构造器new一个商品skuPO对象

商品会有不同规格组成的商品sku，例如XX手机，有黄色内存60G、白色内存60G、黄色内存120G、白色内存120G的四种商品sku。就像我们逛淘宝时要买一部手机，必须选择规格型号确定商品sku后才能下单。

所以商品sku也是比较复杂，是基于部分商品信息又增加了sku规格信息，相当于是商品的子表。由于很多业务功能例如添加秒杀商品的功能中，是根据商品sku操作的，所以shop系统是直接将部分商品信息存储到了sku表里面，这样查询时直接查询sku表就可以了，如果修改商品信息了，也会修改商品sku里面对应的信息，然后新增或更新~

说的很简单，但是具体是有些复杂滴。

首先，由于sku是多个，所以需要for循环创建GoodsSku并set他的信息，每个GoodsSku里面的规格信息分为两种，一种是原始固定必有的（"sn", "cost", "price", "quantity", "weight"），一种是用户自定义的（"颜色"，"内存"等），对于固定的，我们使用固定字段就可以，对于自定义的就只能使用json形式存储了，也方便获取。

由于构建skulist都很多地方都会复用，所以直接抽象成Builder更方便~