[[401825]]

圖片來自 Pexels

本案例只是簡單的模擬，可能與真實的情況有出入，這里只是為了舉例使用。

案例：用戶挑選商品放入購物車，然后下單結算。

流程如下：挑選商品→下單→結算→生成訂單→通知。

提交下單的業務邏輯如下：驗證賬號是否合法→調用第三方接口查看商品的打折價格→錢包金額扣除→生成訂單信息→通知用戶下單成功，等待收貨。

代碼實現：

@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 { 
        // 驗證賬號 
        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()) { 
            // 如果商品價格 - 優惠價格 > 用戶錢包，則說明不夠付 
            return Result.fail("余額不足"); 
        } 
        // 錢包夠付，扣除金額 
        double remain = money.getRemain() - actualPayment; 
        money.setRemain(remain); 
        // 更新賬號錢包余額 
        userMapper.update(userDO); 
        // 生成訂單信息 
        OrderDO orderDO = new OrderDO(); 
        orderDO.setUserId(userId); 
        orderDO.setProductId(productId); 
        orderMapper.save(orderDO); 
        // 通知用戶訂單已生成，等待收貨 
        kafkaTemplate.send("orderTopic", orderDO); 
        return Result.ok(); 
    } 
} 

上面代碼寫好了，而且可以實現相關功能，但是隨著業務的迭代，可能會出現很多問題。

①可維護性差

XxMapper 是基于 Mybatis 實現數據操作層，也就把技術細節帶入業務邏輯中了，如果技術實現變了(改為使用 Hibernate，或 Mybatis 版本升級造成用法改變等)，業務代碼就得改變。

XxDO 是和數據表綁定的，數據表結構變更等也會影響業務代碼。

調用第三方 API，直接在業務代碼中調用 HttpUtils 完成，未來第三方 API 修改了方法簽名或返回值，或改為了 RPC 接口，那么業務代碼也會隨著改變。

發送消息直接使用 KafkaTemplate，如果技術選型變了要改為使用 RocketMQ，那么業務代碼還得變。

②可擴展性差

如果商品因為做活動又加了其他的優惠，或商品某一段時間不打折了，那么原有的代碼就會重新改來改去。

業務邏輯和數據存儲結構是強依賴的，數據存儲結構的變化對業務的影響可想而知。

③可測試性差

因為直接依賴了數據庫，第三方接口，中間件，所以需要所有技術實現后才能進行測試，測試成本和時間都比較大。

代碼優化一

我們上面說了，數據庫操作不應該直接暴露在業務邏輯中，因此把數據庫操作“隔離”開。

public interface UserRepository { 
    User findById(Long userId); 
} 

新增 XxRepository 接口，業務邏輯直接依賴接口/抽象，而不應該直接依賴實現。

Repository 是數據倉庫，不一定非得是 DB，也可以是其他的數據操作。

Repository 返回的對象也不是 DO，與數據庫結構無關。

代碼優化二

DO 對象是只有 set、get 操作，沒有其他行為，我們說這有時是一種貧血現象，會導致本該在業務領域實體中完成的事情散落到各個 Service 中，低內聚而且也不好維護。

增加領域實體，相關行為直接在實體內完成(高內聚)：

public class Money { 
    private double remain; 
    public double getRemain() { 
        return remain; 
    } 
    public void setRemain(double remain) { 
        this.remain = remain; 
    } 
    /** 
     * 扣費 
     * @param delta 
     * @return 
     */ 
    public boolean charge(double delta) { 
        if (remain < delta) { 
            return false; 
        } 
        this.remain -= delta; 
        return true; 
    } 
} 

代碼優化三

第三方接口是不可靠的，方法簽名或返回值或調用方式都有可能會變的，如果直接在業務中依賴，會對業務造成“腐蝕”，所以應該加一層適配層(也叫防腐層 ACL)。

/** 
 * 防腐層/適配層 
 */ 
@Service 
public class PayServiceImpl implements PayService { 
 
    @Autowired 
    private DiscountFacade discountFacade; 
 
    /** 
     *  支付 
     * @param money 
     * @param product 
     * @return 
     */ 
    public boolean pay(Money money, Product product) { 
        // 獲取優惠 
        Double delta = discountFacade.getDiscount(product.getId()); 
        // 扣除費用 
        return money.charge(product.getPrice() - delta); 
    } 
} 

代碼優化四

抽象中間件，不直接依賴具體的 MQ 實現：

public interface MessageProducer<T, R> { 
    Result<R> send(T message); 
} 

總結

優化后的代碼如下：

@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 { 
    // 驗證 
    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("費用扣除失敗"); 
    } 
    // 更新賬戶 
    userRepository.update(user); 
    // 生成訂單信息 
    Order order = OrderFactory.create(user, product); 
    orderRepository.add(order); 
    // 通知用戶訂單已生成，等待收貨 
    messageProducer.send(order); 
    return Result.ok(); 
} 

代碼不一定非常嚴謹，只是通過這一個簡單的例子告訴大家實際工作中代碼該怎么寫，該遵循哪些目標。

①獨立于框架：架構不應該依賴某個外部的庫或框架，不應該被框架的結構所束縛。

②獨立于 UI：前臺展示的樣式可能會隨時發生變化(今天可能是網頁、明天可能變成 console、后天是獨立 app)，但是底層架構不應該隨之而變化。

③獨立于底層數據源：無論今天你用 MySQL、Oracle 還是 MongoDB、CouchDB，甚至使用文件系統，軟件架構不應該因為不同的底層數據儲存方式而產生巨大改變。

④獨立于外部依賴：無論外部依賴如何變更、升級，業務的核心邏輯不應該隨之而大幅變化。

⑤可測試：無論外部依賴了什么數據庫、硬件、UI 或者服務，業務的邏輯應該都能夠快速被驗證正確性。

作者：構即人生

編輯：陶家龍

出處：toutiao.com/i6903053083555807752/