正文

在电商里面处理复杂的业务逻辑场景很多，我们还是以创建商品为列子。很多人可能会问创建商品很复杂吗?我们接着往下看就知道了。

创建商品流程：

• 参数必填性校验
• 参数数据转换
• 商品基础信息校验
• 商品与商家之间的校验
• 类目信息校验
• 商品交易信息校验(这个看公司业务决定)
• SKU相关信息校验
• 商品是否需要有特定标签校验(看公司业务决定)
• 商品类型校验(普通，卡片，视频…….)
• 商品风控校验
• 保存商品信息
• 保存SKU信息
• 保存商品详情信息
• 重量模版
• 运费
• 配送区域
• 。。。。。。。

大家现在看看觉得创建一个上还简单吗?这里商品类型里面还涉及到各个业务场景校验，我们就先不谈了。针对这样的情况我们应该怎么去写这个代码呢?我翻看了一下以前大学写的一些代码整体的代码格式大概也就是这个样子

这么写其实也没有什么问题，功能也能实现。但是这么写其实有很多弊端的：

• 代码可读性不高
• 代码扩展性不高
• 耦合性太强，有些东西不好公用
• (重点)整体创建执行流程时间太长，串行调用下游服务

看到这样代码我们首先都是吐槽一顿，然后还是老老实实是去改。有动手能力强的同学可能会想着去优化一下。再看看这个流程，其实在创建商品的时候我们很多校验和保存数据是m没有依赖且互不影响的，我们完全可以去并行执行。

节省创建商品的流程时间，提高用户体验。(PS：就好比两条高速一条堵车，一条畅通无阻，选哪条?)所以针对这么并行问题我还是给大家画了一个流程图：