遮天辰东小说,网络小说排行榜,完美世界有声小说

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

“整潔架構(gòu)”和商家前端的重構(gòu)之路

?1. 背景

團(tuán)隊歸屬于后方業(yè)務(wù)支撐部門，組內(nèi)的項目都以 pc 中后臺應(yīng)用為主。對比移動端應(yīng)用，代碼庫比較龐大，業(yè)務(wù)邏輯也相對復(fù)雜。在持續(xù)的迭代過程中，我們發(fā)現(xiàn)當(dāng)前的代碼倉庫仍然有不少可以優(yōu)化的點(diǎn)：

創(chuàng)新互聯(lián)專注于哈爾濱企業(yè)網(wǎng)站建設(shè),響應(yīng)式網(wǎng)站,商城網(wǎng)站制作。哈爾濱網(wǎng)站建設(shè)公司,為哈爾濱等地區(qū)提供建站服務(wù)。全流程定制網(wǎng)站開發(fā)，專業(yè)設(shè)計，全程項目跟蹤，創(chuàng)新互聯(lián)專業(yè)和態(tài)度為您提供的服務(wù)

可以減弱對 ui 框架的依賴

21 年前端平臺決定技術(shù)棧統(tǒng)一遷移到 React 生態(tài)，后續(xù)平臺的基礎(chǔ)建設(shè)也都圍繞 React 展開，這就使得商家使用 Vue 生態(tài)做開發(fā)的系統(tǒng)面臨技術(shù)棧遷移的難題，將業(yè)務(wù)邏輯和 UI 框架節(jié)藕變得異常重要。

代碼風(fēng)格可以更加統(tǒng)一

隨著代碼量和團(tuán)隊成員的增加，應(yīng)用里風(fēng)格迥異的代碼也越來越多。為了能夠持續(xù)迅速的進(jìn)行迭代，團(tuán)隊急需一套統(tǒng)一的頂層代碼架構(gòu)設(shè)計方案。

可以集成自動化測試用例

隨著業(yè)務(wù)變得越來越復(fù)雜，在迅速的迭代過程中團(tuán)隊需要頻繁地對功能進(jìn)行回歸，因此我們對于自動化單測用例的訴求也變的越來越強(qiáng)烈。

為了完成以上的優(yōu)化，四組對現(xiàn)有的應(yīng)用架構(gòu)做了一次重構(gòu)，而重構(gòu)的核心就是整潔架構(gòu)。

2. 整潔架構(gòu) (The Clean Architecture)

整潔架構(gòu) (The clean architecture) 是由 Robert C. Martin (Uncle Bob) 在 2012 年提出的一套代碼組織的理念，其核心主要是依據(jù)各部分代碼作用的不同將其拆分成不同的層次，在各層次間制定了明確的依賴原則，以達(dá)到以下目的：

與框架無關(guān)：無論是前端代碼還是服務(wù)端代碼，其邏輯本身都應(yīng)該是獨(dú)立的，不應(yīng)該依賴于某一個第三方框架或工具庫。一套獨(dú)立的代碼可以把第三方框架等作為工具使用。
可測試：代碼中的業(yè)務(wù)邏輯可以在不依賴 ui、數(shù)據(jù)庫、服務(wù)器的情況下進(jìn)行測試
和 ui 無關(guān)：代碼中的業(yè)務(wù)邏輯不應(yīng)該和 ui 做強(qiáng)綁定。比如把一個 web 應(yīng)用切換成桌面應(yīng)用，業(yè)務(wù)邏輯不應(yīng)該受到影響。
和數(shù)據(jù)庫無關(guān)：無論數(shù)據(jù)庫用的是 mysql 還是 mongodb，無論其怎么變，都不該影響到業(yè)務(wù)邏輯。
和外部服務(wù)無關(guān)：無論外部服務(wù)怎么變，都不影響到使用該服務(wù)的業(yè)務(wù)邏輯。

為了實(shí)現(xiàn)以上目的，整潔架構(gòu)把應(yīng)用劃分成了 entities、use cases、interface adapters (MVC、MVP 等)、Web/DB 等至少四層。這套架構(gòu)除了分層之外，在層與層之間還有一個非常明確的依賴關(guān)系，外層的邏輯依賴內(nèi)層的邏輯。

Entity

entities 封裝了企業(yè)級的業(yè)務(wù)邏輯和規(guī)則。entities 沒有什么固定的形式，無論是一個對象也好，是一堆函數(shù)的集合也好，唯一的標(biāo)準(zhǔn)就是能夠被企業(yè)的各個應(yīng)用所復(fù)用。

Use Case

entities 封裝了企業(yè)里最通用的一部分邏輯，而應(yīng)用各自的業(yè)務(wù)邏輯就都封裝在 use case 里面。日常開發(fā)中最常見的對于某個模型的 crud 操作就屬于 usecase 這一層。

Interface Adapter

這一層類似于膠水層，需要負(fù)責(zé)內(nèi)圈的 entity 和 use case 同外圈的 external interfaces 之間的數(shù)據(jù)轉(zhuǎn)化。需要把外層服務(wù)的數(shù)據(jù)轉(zhuǎn)化成內(nèi)層 entity 和 usecase 可以消費(fèi)的數(shù)據(jù)，反之亦然。如上面圖上畫的，這一層有時候可能很簡單 (一個轉(zhuǎn)化函數(shù))，有時候可能復(fù)雜到包含一整個 MVC/MVP 的架構(gòu)。

External Interfaces

我們需要依賴的外部服務(wù)，第三方框架，以及需要糊的頁面 UI 都?xì)w屬在這一層。這一層完全不感知內(nèi)圈的任何邏輯，所以無論這一層怎么變 (ui 變化)，都不應(yīng)該影響到內(nèi)圈的應(yīng)用層邏輯 (usecase) 和企業(yè)級邏輯 (entity)。

依賴原則

在整潔架構(gòu)的原始設(shè)計中，并不是強(qiáng)制一定只能寫這么四層，根據(jù)業(yè)務(wù)的需要還可以拆分的更細(xì)。不過無論怎么拆，都需要遵守前面提到的從外至內(nèi)的依賴原則。即 entity 作為企業(yè)級的通用邏輯，不能依賴任何模塊。而外層的 ui 等則可以使用 usecase、entity。

3. 重構(gòu)

前面介紹了當(dāng)前代碼庫目前的一些具體問題，而整潔架構(gòu)的理念正好可以幫助我們優(yōu)化代碼可維護(hù)性。

作為前端，我們的業(yè)務(wù)邏輯不應(yīng)該依賴視圖層 (ui 框架及其生態(tài))，同時應(yīng)當(dāng)保證業(yè)務(wù)邏輯的獨(dú)立性和可復(fù)用性 (usecase & entity)。最后，作為數(shù)據(jù)驅(qū)動的端應(yīng)用，要保證應(yīng)用視圖渲染和業(yè)務(wù)邏輯等不受數(shù)據(jù)變動的影響 (adapter & entity)。

根據(jù)以上的思考，我們對 “整潔架構(gòu)” 做了如下落地。

Entities

對于前端應(yīng)用來說，在 entity 層我們只需要將服務(wù)端的生數(shù)據(jù)做一層簡單的抽象，生成一個貧血對象給后續(xù)的渲染和交互邏輯使用。

interface IRawOrder {
  amount: number
  barCode: string
  orderNo: string
  orderType: string
  skuId: number
  deliveryTime: number
  orderTime: number
  productImg: string
  status: number
}

export default function buildMakeOrder({
  formatTimestamp,
  formatImageUrl,
}: {
  formatTimestamp: (timestamp: number, format?: string) => string
  formatImageUrl: (
    image: string,
    config?: { width: number; height: number },
  ) => string
}) {
  return function makeOrder(raw?: IRawOrder) {
    if (!raw || !raw.orderNo) {
       Monitor.warn('臟數(shù)據(jù)')
       return null;
    }
    return {
      amount: raw.amount,
      barCode: raw.barCode,
      orderNo: raw.orderNo,
      orderType: raw.orderType,
      skuId: raw.skuId,
      status: raw.status,
      statusDescription: selectStatusDescription(raw.status),
      deliveryTime: formatTimestamp(raw.deliveryTime),
      orderTime: formatTimestamp(raw.orderTime),
      productImg: formatImageUrl(raw.productImg),
    }
  }
}

function selectStatusDescription(status: number): string {
  switch (status) {
    case 0:
      return '待支付'
    case 1:
      return '待發(fā)貨'
    case 2:
      return '待收貨'
    case 3:
      return '已完成'
    default:
      return ''
  }
}

以上是商家后臺訂單模型的 entity 工廠函數(shù)，工廠主要負(fù)責(zé)對服務(wù)端返回的生數(shù)據(jù)進(jìn)行加工處理，讓其滿足渲染層和邏輯層的要求。除了抽象數(shù)據(jù)之外，可以看到在 entity 工廠還對數(shù)據(jù)進(jìn)行了校驗，將臟數(shù)據(jù)、不符合預(yù)期的數(shù)據(jù)全部處理掉或者進(jìn)行兜底 (具體操作要看業(yè)務(wù)場景)。

有一點(diǎn)需要注意的是，在設(shè)計 entity 的時候 (尤其是基礎(chǔ) entity) 需要考慮復(fù)用性。舉個例子，在上面 orderEntity 的基礎(chǔ)上，我們通過簡單的組合就可以生成一個虛擬商品訂單 entity：

import { makeOrder } from '@/entities'

export default function buildMakeVirtualOrder() {
  return function makeVirtualOrder(raw?: IRawPresaleOrder) {
     const order = makeOrder(raw)

     if(! order || !raw.virtualOrderType) {
         Monitor.warn('臟數(shù)據(jù)')
         return null
     }

     return {
         ...order,
         virtualOrderType: raw.virtualOrderType,
         virtualOrderDesc: selectVirtualOrderDesc(raw.virtualOrderType)
     }
  }
}

如此一來，我們就通過 entity 層達(dá)到了兩個目的：

把前端的邏輯和服務(wù)端接口數(shù)據(jù)隔離開，無論服務(wù)端怎么變，前端后續(xù)的渲染、業(yè)務(wù)代碼不需要變，我們只需要變更 entitiy 工廠函數(shù)；并且經(jīng)過 entity 層處理過后，所有流入后續(xù)渲染 & 交互邏輯的數(shù)據(jù)都是可靠的；對于部分異常數(shù)據(jù)，前端應(yīng)用可以第一時間發(fā)現(xiàn)并報警。
通過對業(yè)務(wù)模型進(jìn)行抽象，實(shí)現(xiàn)了模塊間的組合、復(fù)用。另外，抽象出的 entity 對代碼的維護(hù)性也有非常大的幫助，開發(fā)者可以非常直觀的知道所使用的 entity 所包含的所有字段。

Usecase

usecase 這一層即是圍繞 entity 展開的一系列 crud 操作，以及為了頁面渲染做的一些聯(lián)動 (通過 ui store 實(shí)現(xiàn))。由于當(dāng)前架構(gòu)的原因 (沒有 bff 層)，usecase 還可能承擔(dān)部分微服務(wù)串聯(lián)的工作。

舉個例子，商家后臺訂單頁面在渲染前有一堆準(zhǔn)備邏輯：

根據(jù) route 的 query 參數(shù)以及一些商家類型參數(shù)來決定默認(rèn)選中哪個 tab
根據(jù)是國內(nèi)商家還是境外商家，調(diào)用對應(yīng)的供應(yīng)商接口來更新供應(yīng)商下拉框

現(xiàn)在大致的實(shí)現(xiàn)是：

{
    mounted() {
        const { subType } = this.$route.query
        /*
            7-15行處理了幾種分支鏈路場景下對subType的賦值問題
        */
        if (Number(subType) === 0 || subType) {
          this.subType = subType.toString()
        } else {
          if (this.user.merchant.typeId === 4) {
            this.subType = this.tabType.cross
          } else {
            this.subType = this.tabType.ordinarySpot
          }
        }

        /*
            getAllLogisticsCarrier有沒有對subType賦值呢？光看這段代碼完全不確定
        */
        this.getAllLogisticsCarrier()
        /*
            21-22行又多出來一個分支需要對subType進(jìn)行再次賦值
        */
        if (this.isPersonPermission && !this.crossUser) {
          this.subType = this.tabType.warehouse
        }
    },

    getAllLogisticsCarrier() {
        let getCarrier = API.getAllLogisticsCarrier
        if (this.crossUser) {
          getCarrier = API.getOrderShipAllLogistics
        }

        getCarrier({}).then(res => {
          if (res.code === 200) {
            const options = []

            .......... // 給options賦值

            this.options2 = options

          }
        })
    }，
}

我們能看到 7-15、24-125 行對 this.subType 進(jìn)行了賦值。但由于我們無法確定 20 行的函數(shù)是否也對 this.subType 進(jìn)行了賦值，所以光憑 mounted 函數(shù)的代碼我們并不能完全確定 subType 的值究竟是什么，需要跳轉(zhuǎn)到 getAllLogisticsCarrier 函數(shù)確認(rèn)。這段代碼在這里已經(jīng)做了簡化，實(shí)際的代碼像 getAllLogisticsCarrier 這樣的調(diào)用還有好幾個，要想搞清楚邏輯就得把所有函數(shù)全看一遍，代碼的可讀性一般。同時，由于函數(shù)都封裝在 ui 組件里，因此要想給函數(shù)覆蓋單測的話也需要一些改造。

為了解決問題，我們將這部分邏輯都拆分到 usecase 層：

// prepare-order-page.ts
import { tabType } from '@/constants'

interface IParams {
  subType?: number
  merchantType: number
  isCrossUser: boolean
  isPersonPermission: boolean
}

/*
    做依賴倒置主要是為了方便后續(xù)的單測和復(fù)用
*/
export default function buildPrepareOrderPage({
  queryLogisticsCarriers,
}: {
  queryLogisticsCarriers: () => Promise<{ carriers: ICarrires }>
}) {
  return async function prepareOrderPage(params: IParams) {
    const activeTab = selectActiveTab(params)

    const { carriers } = queryLogisticsCarriers(params.isCrossUser)

    return {
      activeTab,
      carriers,
    }
  }
}

function selectActiveTab({
  subType,
  isCrossUser,
  isPersonPermission,
  merchantType,
}: IParams) {
  if (isPersonPermission && !isCrossUser) {
    return tabType.warehouse
  }

  if (Number(subType) === 0 || subType) {
    return subType.toString()
  }

  if (merchantType === 4) {
    return tabType.cross
  }

  return tabType.ordinarySpot
}

// query-logistics-carriers
export default function buildQueryLogisticsCarriers({
  fetchAllLogisticsCarrier,
  fetchOrderShipAllLogistics,
}: {
  fetchAllLogisticsCarrier: () => Promise<{ data: {carriers: ICarrires }}>
  fetchOrderShipAllLogistics: () => Promise<{ data: {carriers: ICarrires }}>
}) {
  return async function queryLogisticsCarriers(isCrossUser: boolean) {
    if (isCrossUser) {
      return fetchAllLogisticsCarrier()
    }

    return fetchOrderShipAllLogistics()
  }
}

// index.vue
{
    mounted() {
        const {activeTab, carriers} = prepareOrderPage(params)

        this.subType = activeTab;
        this.options = buildCarrierOptions(carriers) // 將carries轉(zhuǎn)換成下拉框option
    }
}

首先，可以看到所有 usecase 一定是一個純函數(shù)，不會存在副作用的問題。

其次，prepareOrderPage usecase 專門為訂單頁定制，拆分后一眼就能看出來訂單頁的準(zhǔn)備工作需要干決定選中的 tab 和拉取供應(yīng)商列表兩件事情。而另一個拆分出來的 queryLogisticsCarriers 則是封裝了商家后臺跨境、國內(nèi)兩種邏輯，后續(xù)無論跨境還是國內(nèi)的邏輯如何變更，其影響范圍被限制在了 queryLogisticsCarriers 函數(shù)，我們需要對其進(jìn)行功能回歸；而對于 prepareOrderPage 來說，queryLogisticsCarriers 只是 () => Promise<{ carriers: ICarrires }> 的一個實(shí)現(xiàn)而已，其內(nèi)部調(diào)用 queryLogisticsCarriers 的邏輯完全不受影響，不需要進(jìn)行回歸。

最后，而由于我們做了依賴倒置，我們可以非常容易的給 usecase 覆蓋單測：

import buildPrepareOrderPage from '@/utils/create-goods';

function init() {
  const queryLogisticsCarriers = jest.fn();

  const prepareOrderPage = buildPrepareOrderPage({ queryLogisticsCarriers });

  return {
    prepareOrderPage,
    queryLogisticsCarriers,
  };
}

describe('訂單頁準(zhǔn)備邏輯', () => {
  it('當(dāng)用戶是國內(nèi)商家且在入倉白名單上，在打開訂單頁時，默認(rèn)打開入倉tab', async () => {
    const { prepareOrderPage } = init();
    const params = {
        merchantType: 2
        isCrossUser: false
        isPersonPermission: true
    }

    const { activeTab } = await prepareOrderPage(params)

    expect(activeTab).toEqual({tabType.warehouse});
  });

   it('當(dāng)用戶是跨境商家，在打開訂單頁時，默認(rèn)打開跨境tab', async () => {
    const { prepareOrderPage } = init();
    const params = {
        merchantType: 4
        isCrossUser: true
        isPersonPermission: true
    }

    const { activeTab } = await prepareOrderPage(params)

    expect(activeTab).toEqual({tabType.cross});
  });

  ......
});

單測除了進(jìn)行功能回歸之外，它的描述 (demo 里使用了 Given-When-Then 的格式，由于篇幅的原因，關(guān)于單測的細(xì)節(jié)在后續(xù)的文章再進(jìn)行介紹) 對于了解代碼的邏輯非常非常非常有幫助。由于單測和代碼邏輯強(qiáng)行綁定的緣故，我們甚至可以將單測描述當(dāng)成一份實(shí)時更新的業(yè)務(wù)文檔。

除了方便寫單測之外，在通過 usecase 拆分完成之后，ui 組件真正成為了只負(fù)責(zé) “ui” 和監(jiān)聽用戶交互行為的組件，這為我們后續(xù)的 React 技術(shù)棧遷移奠定了基礎(chǔ)；通過 usecase 我們也實(shí)現(xiàn)了很不錯的模塊化，對于使用比較多的一些 entity，他的 crud 操作可以通過獨(dú)立的 usecase 具備了在多個頁面甚至應(yīng)用間復(fù)用的能力。

Adapter

上面 usecase 例子中的 fetchAllLogisticsCarrier 就是一個 adapter，這一層起到的作用是將外部系統(tǒng)返回的數(shù)據(jù)轉(zhuǎn)化成 entity，并以一種統(tǒng)一的數(shù)據(jù)格式返回回來。

這一層很核心的一點(diǎn)即是可以依賴 entity 的工廠函數(shù)，將接口返回的數(shù)據(jù)轉(zhuǎn)化成前端自己設(shè)計的模型數(shù)據(jù)，保證流入 usecase 和 ui 層的數(shù)據(jù)都是經(jīng)過處理的 “干凈數(shù)據(jù)”。除此之外，通常在這一層我們會用一種固定的數(shù)據(jù)格式返回數(shù)據(jù)，比如例子中的 {success: boolean, data?: any}。這樣做主要是為了抹平對接多個系統(tǒng)帶來的差異性，同時減少多人協(xié)作時的溝通成本。


type Request = (url: string, params: Record) => Promise;
import makeCarrier from '@/entities/makeCarrier'


export default function buildFetchAllLogisticsCarrier({request}: {request: Request}) {
  return async function fetchAllLogisticsCarrier() {
    // TODO: 異常處理
    const response = await request('/fakeapi', info)

    if (!response || !resposne.code === 200) {
        return { 
            success: false
        }
    }

    return {
      success: true,
      data: {
          carriers: response.list?.map(makeCarrier)
      }
    }
  }
}

通過 Adapter + entity 的組合，我們基本形成了前端應(yīng)用和后端服務(wù)之間的防腐層，使得前端可以在完全不清楚接口定義的情況下完成 ui 渲染、usecase 等邏輯的開發(fā)。在服務(wù)端產(chǎn)出定義后，前端只需要將實(shí)際接口返回適配到自己定義的模型 (通過 entity) 即可。這一點(diǎn)對前端的測試周提效非常非常非常重要，因為防腐層的存在，我們可以在測試周完成需求評審之后根據(jù) prd 的內(nèi)容設(shè)計出業(yè)務(wù)模型，并以此完成需求開發(fā)，在真正進(jìn)入研發(fā)周后只需要和服務(wù)端對接完成 adapter 這一層的適配即可。

在實(shí)踐過程中，我們發(fā)現(xiàn)在對接同一個系統(tǒng)的時候 (對商家來說就是 stark 服務(wù)) 各個 adapter 對于異常的處理幾乎一模一樣 (上述的 11-15 行)，我們可以通過 Proxy 對其進(jìn)行抽離實(shí)現(xiàn)復(fù)用。當(dāng)然，后續(xù)我們也完全有機(jī)會根據(jù)接口定義來自動生成 adapter。

UI

在經(jīng)過前面的拆分之后，無論咱們的 UI 層用 React 還是 Vue 來寫，要做的工作都很簡單了：

監(jiān)聽交互事件并調(diào)用對應(yīng)的 usecase 來進(jìn)行響應(yīng)
通過 usecase 來獲取 entity 數(shù)據(jù)進(jìn)行渲染

由于 entity 已經(jīng)做了過濾和適配處理，所以在 ui 層我們可以放心大膽的用，不需要再寫一堆莫名其妙的判斷邏輯。另外由于 entity 是由前端自己定義的模型，無論開發(fā)過程中服務(wù)端接口怎么變，受影響的都只有 entity 工廠函數(shù)，ui 層不會受到影響。

最后，在 ui 層我們還剩下令人頭痛的技術(shù)棧遷移問題。整個團(tuán)隊目前使用 vue 的項目有 10 個，按迭代頻率和項目規(guī)模遷移的方案可以分為兩類：

迭代頻繁的大應(yīng)用：主要包括代碼行數(shù)較多、邏輯較為復(fù)雜的幾個中大型應(yīng)用。這些應(yīng)用想要一把梭直接完成遷移成本極高，但同時每個迭代又有相當(dāng)?shù)男枨蟆；谶@種情況，對于這三個應(yīng)用我們采取了微前端的方式進(jìn)行遷移。每個應(yīng)用分別起一個對應(yīng)的 React 應(yīng)用，對于新頁面以及部分邏輯已經(jīng)完全和 ui 解藕遷移成本不高的業(yè)務(wù)，都由 React 應(yīng)用來承接，最后通過 module federation 的方式實(shí)現(xiàn)融合。
迭代不頻繁的小應(yīng)用：剩下的應(yīng)用均是復(fù)雜度不高的小應(yīng)用，這部分應(yīng)用迭代的需求不多，以維護(hù)為主。因此我們的方案是對現(xiàn)有邏輯進(jìn)行整潔架構(gòu)重構(gòu)，在 ui 和邏輯分層之后直接對 ui 層進(jìn)行替換完成遷移。

4. 后續(xù)

通過整潔架構(gòu)我們形成了統(tǒng)一的編碼規(guī)范，在前端應(yīng)用標(biāo)準(zhǔn)化的道路上邁下了堅實(shí)的一步?？梢灶A(yù)見的是整個標(biāo)準(zhǔn)化的過程會非常漫長，我們會陸續(xù)往標(biāo)準(zhǔn)中增加新的規(guī)范使其更加完善，短期內(nèi)在規(guī)劃中的有：

單測即文檔：上面提到了 usecase 通過依賴倒置來配合單測落地，后續(xù)團(tuán)隊期望將一些業(yè)務(wù)邏輯的實(shí)現(xiàn)細(xì)則通過單測的描述來進(jìn)行沉淀，解決業(yè)務(wù)文檔實(shí)時性的問題。
完善監(jiān)控體系：前端常遇到的 3 種異常包括代碼邏輯異常、性能瓶頸 (渲染卡頓、內(nèi)存不足等)、數(shù)據(jù)導(dǎo)致異常。對于數(shù)據(jù)異常，我們可以在 entity 層映射的過程中加入對異常數(shù)據(jù)的埋點(diǎn)上報來填補(bǔ)目前監(jiān)控的空白。（代碼邏輯異常通過 sentry 已經(jīng)監(jiān)控，性能監(jiān)控對于中后臺應(yīng)用不需要）?

當(dāng)前標(biāo)題：“整潔架構(gòu)”和商家前端的重構(gòu)之路
分享網(wǎng)址：http://fisionsoft.com.cn/article/djhdjhc.html