干凈的前端架構,圍繞這個話題有很多原則:
SOLID、KISS(保持簡單明了)、DRY(不要重復自己)、DDD(領域驅動設計)等等。
功能性和非功能性的要求不僅應該在后端應用,還應該在前端應用。因此,有了前端架構,我們就能滿足業務需求。此外,我們能夠更好地理解項目的復雜性,從而降低項目的風險、時間和成本。然而,作者認為,前端架構的最有價值的原因是任何項目的可維護性和可擴展性。
根據作者的經驗,大多數時候都使用分層架構。但是,也會有一些項目采用了六邊形架構。
下圖簡單地描繪了一個TripAgency項目。
那么,如果沒有定義規則,開發人員就可能直接在其組件中使用 DTO,或者在沒有存儲的情況下與服務層通信。或者更糟糕的是,啞組件會與服務層對話。
只需定義一些規則來防止這種情況發生即可。最常見的方法之一就是在項目中引入 Bit 或 Nx。
什么是 Bit?什么是 Nx?
Bit 和 Nx 是功能強大的開源構建系統,可提供用于提高開發人員工作效率、優化 CI 性能和維護代碼質量的工具和技術
因此,在使用 Bit 或 Nx 時,我們可能會應用依賴規則。因此,如果使用了錯誤的層,開發人員就會出錯。
我們可以將一些 DDD(域驅動設計)概念應用到我們的 Booking 域中。因此,我們將預訂域劃分為一些子域。每個子域都有自己的邊界上下文和泛在語言。如下圖所示。
每個子域使用分層架構,這些子域之間的交互使用 API。功能包括智能組件和服務、用戶界面(UI)、啞組件、域模型和 Util 所有實用功能,這些功能都在此邊界上下文中使用。我們已經很接近了,但還沒到那一步。僅有架構是不夠的,底層組件和業務邏輯也必須使用清潔代碼原則。因此,讓我們放大功能層和用戶界面層。
首先是 SOLID 原則。每個組件必須只有一個責任(單一責任原則)。使用組合而非繼承(開放-封閉原則)。不要強迫組件實現不合適的接口,這意味著并非所有方法都有意義(接口隔離)。
其次,在將業務邏輯應用到組件、服務或 Util 時,不要忘記 KISS 原則。代碼要盡可能簡短。為什么要這樣做呢?更簡單的代碼更容易維護。
第三,盡量不要重復(DRY 原則)。將常用邏輯移至實用工具或服務中。
注:這些原則可以通過使用 Bit 輕松實現。在 Bit 工作區內,我們可以獨立構建、測試、版本控制和記錄可重復使用的組件(函數、用戶界面元素或數據模型),然后將其發布到 Bit 的組件共享平臺,在該平臺上,你(或其他人)可以輕松地將其導入到多個項目中。
聽起來很有道理。然而,如何才能知道哪些是應該避免的呢?簡而言之,什么是反模式?
有一些比較常見的錯誤?
所以,這些都是反模式。但如何確保代碼的可維護性呢?大家可能都知道,業務邏輯會隨著時間的推移而增長。簡而言之,經常會聽到以下說法。
代碼有了歷史性的發展。起初,它是 "干凈代碼"(Clean Code),但現在我們的代碼已經無法像以前那樣容易維護了。
是的,這是一個非常常見的問題。不過,以下簡單的規則可以幫助我們保持可維護性。
本文介紹了一個簡潔架構的例子,并概述了一些可以應用的原則。此外,還將 DDD 引入了前端架構。最后,介紹了創建組件和添加業務邏輯時的一些規則,希望這些代碼能夠保持可維護性。
不過,開發人員團隊在進行代碼審查和添加新功能時必須具備較高的標準,否則清潔架構可能不足以保持可維護性。
希望這能幫助大家構建更簡潔的前端架構。
本文鏈接:http://www.www897cc.com/showinfo-26-31539-0.html干凈的前端架構,看完這篇讓你能夠構建更簡潔的前端架構
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
下一篇: 各類語言真實性能比較列表