烦死了，业务代码老写不好...
发布时间：2021-05-26 21:01:53来源：51CTO技术栈
“
本文举一个非常简单的例子，以案例的业务实现来分析如何写好业务代码。
图片来自Pexels
本案例只是简单的模拟，可能与真实的情况有出入，这里只是为了举例使用。
案例：用户挑选商品放入购物车，然后下单结算。
流程如下：挑选商品→下单→结算→生成订单→通知。
提交下单的业务逻辑如下：验证账号是否合法→调用第三方接口查看商品的打折价格→钱包金额扣除→生成订单信息→通知用户下单成功，等待收货。
@ServicepublicclassOrderServiceImplimplementsOrderService{@AutowiredprivateUserMapperuserMapper;@AutowiredprivateProductMapperproductMapper;@AutowiredprivateOrderMapperorderMapper;@AutowiredprivateKafkaTemplatekafkaTemplate;/***购买商品，提交订单*@paramuserId用户ID*@paramproductId商品ID*@return*/publicResultsubmit(LonguserId,LongproductId)throwsBizException{//验证账号UserDOuserDO=userMapper.findById(userId);if(userDO==null){throwBizException(USER_NOT_EXISTS);}//查看商品信息及打折信息ProductDOproductDO=productMapper.findById(productId);Doubledelta=HttpUtils.getDiscount(productId);doubleactualPayment=productDO.getPrice()-delta;Moneymoney=userDO.getMoney();if(actualPayment>money.getRemain()){//如果商品价格-优惠价格>用户钱包，则说明不够付returnResult.fail("余额不足");}//钱包够付，扣除金额doubleremain=money.getRemain()-actualPayment;money.setRemain(remain);//更新账号钱包余额userMapper.update(userDO);//生成订单信息OrderDOorderDO=newOrderDO();orderDO.setUserId(userId);orderDO.setProductId(productId);orderMapper.save(orderDO);//通知用户订单已生成，等待收货kafkaTemplate.send("orderTopic",orderDO);returnResult.ok();}}
上面代码写好了，而且可以实现相关功能，但是随着业务的迭代，可能会出现很多问题。
XxMapper是基于Mybatis实现数据操作层，也就把技术细节带入业务逻辑中了，如果技术实现变了（改为使用Hibernate，或Mybatis版本升级造成用法改变等），业务代码就得改变。
XxDO是和数据表绑定的，数据表结构变更等也会影响业务代码。
调用第三方API，直接在业务代码中调用HttpUtils完成，未来第三方API修改了方法签名或返回值，或改为了RPC接口，那么业务代码也会随着改变。
发送消息直接使用KafkaTemplate，如果技术选型变了要改为使用RocketMQ，那么业务代码还得变。
如果商品因为做活动又加了其他的优惠，或商品某一段时间不打折了，那么原有的代码就会重新改来改去。
业务逻辑和数据存储结构是强依赖的，数据存储结构的变化对业务的影响可想而知。
因为直接依赖了数据库，第三方接口，中间件，所以需要所有技术实现后才能进行测试，测试成本和时间都比较大。
代码优化一
我们上面说了，数据库操作不应该直接暴露在业务逻辑中，因此把数据库操作“隔离”开。
publicinterfaceUserRepository{UserfindById(LonguserId);}
新增XxRepository接口，业务逻辑直接依赖接口/抽象，而不应该直接依赖实现。
Repository是数据仓库，不一定非得是DB，也可以是其他的数据操作。
Repository返回的对象也不是DO，与数据库结构无关。
代码优化二
DO对象是只有set、get操作，没有其他行为，我们说这有时是一种贫血现象，会导致本该在业务领域实体中完成的事情散落到各个Service中，低内聚而且也不好维护。
增加领域实体，相关行为直接在实体内完成（高内聚）：
publicclassMoney{privatedoubleremain;publicdoublegetRemain(){returnremain;}publicvoidsetRemain(doubleremain){this.remain=remain;}/***扣费*@paramdelta*@return*/publicbooleancharge(doubledelta){if(remain
代码优化三
第三方接口是不可靠的，方法签名或返回值或调用方式都有可能会变的，如果直接在业务中依赖，会对业务造成“腐蚀”，所以应该加一层适配层（也叫防腐层ACL）。
/***防腐层/适配层*/@ServicepublicclassPayServiceImplimplementsPayService{@AutowiredprivateDiscountFacadediscountFacade;/***支付*@parammoney*@paramproduct*@return*/publicbooleanpay(Moneymoney,Productproduct){//获取优惠Doubledelta=discountFacade.getDiscount(product.getId());//扣除费用returnmoney.charge(product.getPrice()-delta);}}
代码优化四
抽象中间件，不直接依赖具体的MQ实现：
publicinterfaceMessageProducer
总结
优化后的代码如下：
@AutowiredprivateUserRepositoryuserRepository;@AutowiredprivateProductRepositoryproductRepository;@AutowiredprivateOrderRepositoryorderRepository;@AutowiredprivateMessageProducer
代码不一定非常严谨，只是通过这一个简单的例子告诉大家实际工作中代码该怎么写，该遵循哪些目标。
①独立于框架：架构不应该依赖某个外部的库或框架，不应该被框架的结构所束缚。
②独立于UI：前台展示的样式可能会随时发生变化（今天可能是网页、明天可能变成console、后天是独立app），但是底层架构不应该随之而变化。
③独立于底层数据源：无论今天你用MySQL、Oracle还是MongoDB、CouchDB，甚至使用文件系统，软件架构不应该因为不同的底层数据储存方式而产生巨大改变。
④独立于外部依赖：无论外部依赖如何变更、升级，业务的核心逻辑不应该随之而大幅变化。
⑤可测试：无论外部依赖了什么数据库、硬件、UI或者服务，业务的逻辑应该都能够快速被验证正确性。
作者：构即人生
编辑：陶家龙
出处：toutiao.com/i6903053083555807752/
精彩文章推荐：
