如何寫出一手好的業(yè)務(wù)代碼？
點(diǎn)擊上方藍(lán)色字體，選擇“標(biāo)星公眾號(hào)”
優(yōu)質(zhì)文章，第一時(shí)間送達(dá)
說明
這里舉一個(gè)非常簡(jiǎn)單的例子，以案例的業(yè)務(wù)實(shí)現(xiàn)來分析如何寫好業(yè)務(wù)代碼。
本案例只是簡(jiǎn)單的模擬，可能與真實(shí)的情況有出入，這里只是為了舉例使用。
案例：
用戶挑選商品放入購物車，然后下單結(jié)算，流程如下：
挑選商品
下單
結(jié)算
生成訂單
通知
提交下單的業(yè)務(wù)邏輯如下：
驗(yàn)證賬號(hào)是否合法
調(diào)用第三方接口查看商品的打折價(jià)格
錢包金額扣除
生成訂單信息
通知用戶下單成功，等待收貨
代碼實(shí)現(xiàn)
@Service
public class OrderServiceImpl implements OrderService {
@Autowired
private UserMapper userMapper;
@Autowired
private ProductMapper productMapper;
@Autowired
private OrderMapper orderMapper;
@Autowired
private KafkaTemplate kafkaTemplate;
/**
* 購買商品，提交訂單
* @param userId 用戶ID
* @param productId 商品ID
* @return
*/
public Result submit(Long userId, Long productId) throws BizException {
// 驗(yàn)證賬號(hào)
UserDO userDO = userMapper.findById(userId);
if (userDO == null) {
throw BizException(USER_NOT_EXISTS);
}
// 查看商品信息及打折信息
ProductDO productDO = productMapper.findById(productId);
Double delta = HttpUtils.getDiscount(productId);
double actualPayment = productDO.getPrice() - delta;
Money money = userDO.getMoney();
if (actualPayment > money.getRemain()) {
// 如果商品價(jià)格 - 優(yōu)惠價(jià)格 > 用戶錢包，則說明不夠付
return Result.fail("余額不足");
}
// 錢包夠付，扣除金額
double remain = money.getRemain() - actualPayment;
money.setRemain(remain);
// 更新賬號(hào)錢包余額
userMapper.update(userDO);
// 生成訂單信息
OrderDO orderDO = new OrderDO();
orderDO.setUserId(userId);
orderDO.setProductId(productId);
orderMapper.save(orderDO);
// 通知用戶訂單已生成，等待收貨
kafkaTemplate.send("orderTopic", orderDO);
return Result.ok();
}
}
上面代碼寫好了，而且可以實(shí)現(xiàn)相關(guān)功能，但是隨著業(yè)務(wù)的迭代，可能會(huì)出現(xiàn)很多問題：
可維護(hù)性差：
XxMapper是基于Mybatis實(shí)現(xiàn)數(shù)據(jù)操作層，也就把技術(shù)細(xì)節(jié)帶入業(yè)務(wù)邏輯中了，如果技術(shù)實(shí)現(xiàn)變了（改為使用Hibernate，或Mybatis版本升級(jí)造成用法改變等），業(yè)務(wù)代碼就得改變。
XxDO 是和數(shù)據(jù)表綁定的，數(shù)據(jù)表結(jié)構(gòu)變更等也會(huì)影響業(yè)務(wù)代碼。
調(diào)用第三方API，直接在業(yè)務(wù)代碼中調(diào)用HttpUtils完成，未來第三方API修改了方法簽名或返回值，或改為了RPC接口，那么業(yè)務(wù)代碼也會(huì)隨著改變。
發(fā)送消息直接使用KafkaTemplate，如果技術(shù)選型變了要改為使用RocketMQ，那么業(yè)務(wù)代碼還得變。
可擴(kuò)展性差：
如果商品因?yàn)樽龌顒?dòng)又加了其他的優(yōu)惠，或商品某一段時(shí)間不打折了，那么原有的代碼就會(huì)重新改來改去；
業(yè)務(wù)邏輯和數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)是強(qiáng)依賴的，數(shù)據(jù)存儲(chǔ)結(jié)構(gòu)的變化對(duì)業(yè)務(wù)的影響可想而知；
可測(cè)試性差：
因?yàn)橹苯右蕾嚵藬?shù)據(jù)庫，第三方接口，中間件，所以需要所有技術(shù)實(shí)現(xiàn)后才能進(jìn)行測(cè)試，測(cè)試成本和時(shí)間都比較大。
代碼優(yōu)化一
我們上面說了，數(shù)據(jù)庫操作不應(yīng)該直接暴露在業(yè)務(wù)邏輯中，因此把數(shù)據(jù)庫操作“隔離”開
public interface UserRepository {
User findById(Long userId);
}
新增XxRepository接口，業(yè)務(wù)邏輯直接依賴接口/抽象，而不應(yīng)該直接依賴實(shí)現(xiàn)。
Repository是數(shù)據(jù)倉庫，不一定非得是DB，也可以是其他的數(shù)據(jù)操作。
Repository返回的對(duì)象也不是DO，與數(shù)據(jù)庫結(jié)構(gòu)無關(guān)。
代碼優(yōu)化二
DO對(duì)象是只有 set, get操作，沒有其他行為，我們說這有時(shí)是一種貧血現(xiàn)象，會(huì)導(dǎo)致本該在業(yè)務(wù)領(lǐng)域?qū)嶓w中完成的事情散落到各個(gè)Service中，低內(nèi)聚而且也不好維護(hù)。
增加領(lǐng)域?qū)嶓w，相關(guān)行為直接在實(shí)體內(nèi)完成（高內(nèi)聚）：
public class Money {
private double remain;
public double getRemain() {
return remain;
}
public void setRemain(double remain) {
this.remain = remain;
}
/**
* 扣費(fèi)
* @param delta
* @return
*/
public boolean charge(double delta) {
if (remain < delta) {
return false;
}
this.remain -= delta;
return true;
}
}
代碼優(yōu)化三
第三方接口是不可靠的，方法簽名或返回值或調(diào)用方式都有可能會(huì)變的，如果直接在業(yè)務(wù)中依賴，會(huì)對(duì)業(yè)務(wù)造成“腐蝕”，所以應(yīng)該加一層適配層（也叫防腐層ACL）。
/**
* 防腐層/適配層
*/
@Service
public class PayServiceImpl implements PayService {
@Autowired
private DiscountFacade discountFacade;
/**
* 支付
* @param money
* @param product
* @return
*/
public boolean pay(Money money, Product product) {
// 獲取優(yōu)惠
Double delta = discountFacade.getDiscount(product.getId());
// 扣除費(fèi)用
return money.charge(product.getPrice() - delta);
}
}
代碼優(yōu)化四
抽象中間件，不直接依賴具體的MQ實(shí)現(xiàn)
public interface MessageProducer<T, R> {
Result<R> send(T message);
}
總結(jié)
優(yōu)化后的代碼如下：
@Autowired
private UserRepository userRepository;
@Autowired
private ProductRepository productRepository;
@Autowired
private OrderRepository orderRepository;
@Autowired
private MessageProducer<Order,Result> messageProducer;
@Autowired
private PayService payService;
/**
* 購買商品，提交訂單
* @param userId 用戶ID
* @param productId 商品ID
* @return
*/
public Result submit(Long userId, Long productId) throws BizException {
// 驗(yàn)證
User user = userRepository.findByUserId(userId);
if (user == null) {
throw BizException(USER_NOT_EXISTS);
}
// 支付
Product product = productRepository.findById(productId);
boolean f = payService.pay(user.getMoney(), product);
if (!f) {
return Result.fail("費(fèi)用扣除失敗");
}
// 更新賬戶
userRepository.update(user);
// 生成訂單信息
Order order = OrderFactory.create(user, product);
orderRepository.add(order);
// 通知用戶訂單已生成，等待收貨
messageProducer.send(order);
return Result.ok();
}
代碼不一定非常嚴(yán)謹(jǐn)，只是通過這一個(gè)簡(jiǎn)單的例子告訴大家實(shí)際工作中代碼該怎么寫，該遵循哪些目標(biāo)：
獨(dú)立于框架：架構(gòu)不應(yīng)該依賴某個(gè)外部的庫或框架，不應(yīng)該被框架的結(jié)構(gòu)所束縛。
獨(dú)立于UI：前臺(tái)展示的樣式可能會(huì)隨時(shí)發(fā)生變化（今天可能是網(wǎng)頁、明天可能變成console、后天是獨(dú)立app），但是底層架構(gòu)不應(yīng)該隨之而變化。
獨(dú)立于底層數(shù)據(jù)源：無論今天你用MySQL、Oracle還是MongoDB、CouchDB，甚至使用文件系統(tǒng)，軟件架構(gòu)不應(yīng)該因?yàn)椴煌牡讓訑?shù)據(jù)儲(chǔ)存方式而產(chǎn)生巨大改變。
獨(dú)立于外部依賴：無論外部依賴如何變更、升級(jí)，業(yè)務(wù)的核心邏輯不應(yīng)該隨之而大幅變化。
可測(cè)試：無論外部依賴了什么數(shù)據(jù)庫、硬件、UI或者服務(wù)，業(yè)務(wù)的邏輯應(yīng)該都能夠快速被驗(yàn)證正確性。
作者 | 架構(gòu)即人生
來源 | toutiao.com/i6903053083555807752
