如何寫好業(yè)務代碼

說明

這里舉一個非常簡單的例子，以案例的業(yè)務實現(xiàn)來分析如何寫好業(yè)務代碼。

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

案例：

用戶挑選商品放入購物車，然后下單結算，流程如下：

挑選商品 > 下單 > 結算 > 生成訂單 > 通知

提交下單的業(yè)務邏輯如下：

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

代碼實現(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 {
        // 驗證賬號
        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()) {
            // 如果商品價格 - 優(yōu)惠價格 > 用戶錢包，則說明不夠付
            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();
    }
}

上面代碼寫好了，而且可以實現(xiàn)相關功能，但是隨著業(yè)務的迭代，可能會出現(xiàn)很多問題：

可維護性差

1. XxMapper是基于Mybatis實現(xiàn)數(shù)據(jù)操作層，也就把技術細節(jié)帶入業(yè)務邏輯中了，如果技術實現(xiàn)變了（改為使用Hibernate，或Mybatis版本升級造成用法改變等），業(yè)務代碼就得改變。

2. XxDO 是和數(shù)據(jù)表綁定的，數(shù)據(jù)表結構變更等也會影響業(yè)務代碼。

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

4. 發(fā)送消息直接使用KafkaTemplate，如果技術選型變了要改為使用RocketMQ，那么業(yè)務代碼還得變。

可擴展性差

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

2. 業(yè)務邏輯和數(shù)據(jù)存儲結構是強依賴的，數(shù)據(jù)存儲結構的變化對業(yè)務的影響可想而知；

可測試性差

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

代碼優(yōu)化一

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

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

新增 XxRepository 接口，業(yè)務邏輯直接依賴接口/抽象，而不應該直接依賴實現(xiàn)。

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

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

代碼優(yōu)化二

DO 對象是只有 set、get 操作，沒有其他行為，我們說這有時是一種貧血現(xiàn)象，會導致本該在業(yè)務領域實體中完成的事情散落到各個 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;
    }
}

代碼優(yōu)化三

第三方接口是不可靠的，方法簽名或返回值或調用方式都有可能會變的，如果直接在業(yè)務中依賴，會對業(yè)務造成“腐蝕”，所以應該加一層適配層（也叫防腐層 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());
        // 扣除費用
        return money.charge(product.getPrice() - delta);
    }
}

代碼優(yōu)化四

抽象中間件，不直接依賴具體的 MQ 實現(xiàn)

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

總結

優(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 {
    // 驗證
    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：前臺展示的樣式可能會隨時發(fā)生變化（今天可能是網(wǎng)頁、明天可能變成 console、后天是獨立 app），但是底層架構不應該隨之而變化。

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

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

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