分布式系統中的CAP理論，面試必問，你理解了嘛？
對于剛剛接觸分布式系統的小伙伴們來說，一提起分布式系統，就感覺高大上，深不可測。而且看了很多書和視頻還是一臉懵逼。這篇文章主要使用大白話的方式，帶你理解一下分布式系統
干凈的前端架構,圍繞這個話題有很多原則：
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
下一篇： 各類語言真實性能比較列表
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號