新聞中心
圖片來自 Pexels

本案例只是簡單的模擬,可能與真實的情況有出入,這里只是為了舉例使用。
案例:用戶挑選商品放入購物車,然后下單結(jié)算。
流程如下:挑選商品→下單→結(jié)算→生成訂單→通知。
提交下單的業(yè)務(wù)邏輯如下:驗證賬號是否合法→調(diào)用第三方接口查看商品的打折價格→錢包金額扣除→生成訂單信息→通知用戶下單成功,等待收貨。
代碼實現(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)相關(guān)功能,但是隨著業(yè)務(wù)的迭代,可能會出現(xiàn)很多問題。
①可維護(hù)性差
XxMapper 是基于 Mybatis 實現(xiàn)數(shù)據(jù)操作層,也就把技術(shù)細(xì)節(jié)帶入業(yè)務(wù)邏輯中了,如果技術(shù)實現(xiàn)變了(改為使用 Hibernate,或 Mybatis 版本升級造成用法改變等),業(yè)務(wù)代碼就得改變。
XxDO 是和數(shù)據(jù)表綁定的,數(shù)據(jù)表結(jié)構(gòu)變更等也會影響業(yè)務(wù)代碼。
調(diào)用第三方 API,直接在業(yè)務(wù)代碼中調(diào)用 HttpUtils 完成,未來第三方 API 修改了方法簽名或返回值,或改為了 RPC 接口,那么業(yè)務(wù)代碼也會隨著改變。
發(fā)送消息直接使用 KafkaTemplate,如果技術(shù)選型變了要改為使用 RocketMQ,那么業(yè)務(wù)代碼還得變。
②可擴(kuò)展性差
如果商品因為做活動又加了其他的優(yōu)惠,或商品某一段時間不打折了,那么原有的代碼就會重新改來改去。
業(yè)務(wù)邏輯和數(shù)據(jù)存儲結(jié)構(gòu)是強(qiáng)依賴的,數(shù)據(jù)存儲結(jié)構(gòu)的變化對業(yè)務(wù)的影響可想而知。
③可測試性差
因為直接依賴了數(shù)據(jù)庫,第三方接口,中間件,所以需要所有技術(shù)實現(xiàn)后才能進(jìn)行測試,測試成本和時間都比較大。
代碼優(yōu)化一
我們上面說了,數(shù)據(jù)庫操作不應(yīng)該直接暴露在業(yè)務(wù)邏輯中,因此把數(shù)據(jù)庫操作“隔離”開。
- public interface UserRepository {
- User findById(Long userId);
- }
新增 XxRepository 接口,業(yè)務(wù)邏輯直接依賴接口/抽象,而不應(yīng)該直接依賴實現(xiàn)。
Repository 是數(shù)據(jù)倉庫,不一定非得是 DB,也可以是其他的數(shù)據(jù)操作。
Repository 返回的對象也不是 DO,與數(shù)據(jù)庫結(jié)構(gòu)無關(guān)。
代碼優(yōu)化二
DO 對象是只有 set、get 操作,沒有其他行為,我們說這有時是一種貧血現(xiàn)象,會導(dǎo)致本該在業(yè)務(wù)領(lǐng)域?qū)嶓w中完成的事情散落到各個 Service 中,低內(nèi)聚而且也不好維護(hù)。
增加領(lǐng)域?qū)嶓w,相關(guān)行為直接在實體內(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)用方式都有可能會變的,如果直接在業(yè)務(wù)中依賴,會對業(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 實現(xiàn):
- public interface MessageProducer
{ - Result
send(T message); - }
總結(jié)
優(yōu)化后的代碼如下:
- @Autowired
- private UserRepository userRepository;
- @Autowired
- private ProductRepository productRepository;
- @Autowired
- private OrderRepository orderRepository;
- @Autowired
- private MessageProducer
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("費(fèi)用扣除失敗");
- }
- // 更新賬戶
- userRepository.update(user);
- // 生成訂單信息
- Order order = OrderFactory.create(user, product);
- orderRepository.add(order);
- // 通知用戶訂單已生成,等待收貨
- messageProducer.send(order);
- return Result.ok();
- }
代碼不一定非常嚴(yán)謹(jǐn),只是通過這一個簡單的例子告訴大家實際工作中代碼該怎么寫,該遵循哪些目標(biāo)。
①獨(dú)立于框架:架構(gòu)不應(yīng)該依賴某個外部的庫或框架,不應(yīng)該被框架的結(jié)構(gòu)所束縛。
②獨(dú)立于 UI:前臺展示的樣式可能會隨時發(fā)生變化(今天可能是網(wǎng)頁、明天可能變成 console、后天是獨(dú)立 app),但是底層架構(gòu)不應(yīng)該隨之而變化。
③獨(dú)立于底層數(shù)據(jù)源:無論今天你用 MySQL、Oracle 還是 MongoDB、CouchDB,甚至使用文件系統(tǒng),軟件架構(gòu)不應(yīng)該因為不同的底層數(shù)據(jù)儲存方式而產(chǎn)生巨大改變。
④獨(dú)立于外部依賴:無論外部依賴如何變更、升級,業(yè)務(wù)的核心邏輯不應(yīng)該隨之而大幅變化。
⑤可測試:無論外部依賴了什么數(shù)據(jù)庫、硬件、UI 或者服務(wù),業(yè)務(wù)的邏輯應(yīng)該都能夠快速被驗證正確性。
作者:構(gòu)即人生
編輯:陶家龍
出處:toutiao.com/i6903053083555807752/
網(wǎng)頁題目:煩死了,業(yè)務(wù)代碼老寫不好...
標(biāo)題網(wǎng)址:http://m.fisionsoft.com.cn/article/dpsghds.html


咨詢
建站咨詢
