干凈的前端架構,圍繞這個話題有很多原則：

SOLID、KISS（保持簡單明了）、DRY（不要重復自己）、DDD（領域驅動設計）等等。

為什么需要前端架構？

功能性和非功能性的要求不僅應該在后端應用，還應該在前端應用。因此，有了前端架構，我們就能滿足業務需求。此外，我們能夠更好地理解項目的復雜性，從而降低項目的風險、時間和成本。然而，作者認為，前端架構的最有價值的原因是任何項目的可維護性和可擴展性。

那么，前端架構是什么樣的呢？

根據作者的經驗，大多數時候都使用分層架構。但是，也會有一些項目采用了六邊形架構。

下圖簡單地描繪了一個TripAgency項目。

使用了哪些層？

• API：由 Open-API 生成器生成的DTO和服務
• 服務：包括映射器（DTO到前端模型，反之亦然）和使用 REST 端點與 API 通信的服務
• 存儲：包含從服務層檢索到的所有數據
• Booking：包括模型和組件在內的領域。智能組件（ Smart-Components）直接與商店互動，而啞組件（Dumb components）只是可以在多個上下文中應用的組件，因此要簡單得多。

那么，這種架構會出什么問題呢？

那么，如果沒有定義規則，開發人員就可能直接在其組件中使用 DTO，或者在沒有存儲的情況下與服務層通信。或者更糟糕的是，啞組件會與服務層對話。

我們應該如何避免這些錯誤？

只需定義一些規則來防止這種情況發生即可。最常見的方法之一就是在項目中引入 Bit 或 Nx。

什么是 Bit？什么是 Nx？

Bit 和 Nx 是功能強大的開源構建系統，可提供用于提高開發人員工作效率、優化 CI 性能和維護代碼質量的工具和技術

因此，在使用 Bit 或 Nx 時，我們可能會應用依賴規則。因此，如果使用了錯誤的層，開發人員就會出錯。

我們可以將一些 DDD（域驅動設計）概念應用到我們的 Booking 域中。因此，我們將預訂域劃分為一些子域。每個子域都有自己的邊界上下文和泛在語言。如下圖所示。

每個子域使用分層架構，這些子域之間的交互使用 API。功能包括智能組件和服務、用戶界面（UI）、啞組件、域模型和 Util 所有實用功能，這些功能都在此邊界上下文中使用。我們已經很接近了，但還沒到那一步。僅有架構是不夠的，底層組件和業務邏輯也必須使用清潔代碼原則。因此，讓我們放大功能層和用戶界面層。

哪些原則應適用于組件？

首先是 SOLID 原則。每個組件必須只有一個責任（單一責任原則）。使用組合而非繼承（開放-封閉原則）。不要強迫組件實現不合適的接口，這意味著并非所有方法都有意義（接口隔離）。

其次，在將業務邏輯應用到組件、服務或 Util 時，不要忘記 KISS 原則。代碼要盡可能簡短。為什么要這樣做呢？更簡單的代碼更容易維護。

第三，盡量不要重復（DRY 原則）。將常用邏輯移至實用工具或服務中。

注：這些原則可以通過使用 Bit 輕松實現。在 Bit 工作區內，我們可以獨立構建、測試、版本控制和記錄可重復使用的組件（函數、用戶界面元素或數據模型），然后將其發布到 Bit 的組件共享平臺，在該平臺上，你（或其他人）可以輕松地將其導入到多個項目中。

聽起來很有道理。然而，如何才能知道哪些是應該避免的呢？簡而言之，什么是反模式？

Anti-Patterns 反模式

有一些比較常見的錯誤？

• 導入不必要的庫，增大捆綁包大小
• 使用嵌套訂閱
• 在模板中添加業務邏輯
• 未經測試的業務邏輯

所以，這些都是反模式。但如何確保代碼的可維護性呢？大家可能都知道，業務邏輯會隨著時間的推移而增長。簡而言之，經常會聽到以下說法。

代碼有了歷史性的發展。起初，它是 "干凈代碼"（Clean Code），但現在我們的代碼已經無法像以前那樣容易維護了。

是的，這是一個非常常見的問題。不過，以下簡單的規則可以幫助我們保持可維護性。

• 定義eslint規則
• 使用stylelint
• 測試業務邏輯
• 構建小型可重用的組件
• 使用ES6和Typescript功能

總結

本文介紹了一個簡潔架構的例子，并概述了一些可以應用的原則。此外，還將 DDD 引入了前端架構。最后，介紹了創建組件和添加業務邏輯時的一些規則，希望這些代碼能夠保持可維護性。

不過，開發人員團隊在進行代碼審查和添加新功能時必須具備較高的標準，否則清潔架構可能不足以保持可維護性。

希望這能幫助大家構建更簡潔的前端架構。