nextjs clean architecture

Next.js中的清潔體系結構

此存儲庫是如何在Next.js中實現乾淨體系結構的一個示例。有一個視頻教程貫穿該項目。單擊圖像以在YouTube上查看：

您只需運行npm install和npm run dev即可運行項目。

乾淨的體系結構

筆記

？我繪製了原始清潔架構圖的簡化版本。我以一種對我來說更有意義的方式簡化了它，並且更容易理解。我希望它也對您有所幫助。

我強烈建議您閱讀Bob叔叔的原始文章，如果您是您第一次聽到有關乾淨建築的消息，但我會在下面為您總結一下。

乾淨的體系結構是一組規則，可以幫助我們以更易於維護和測試的方式構建應用程序，並且它們的代碼庫是可以預測的。無論他們的技術背景和編程語言偏好如何，這就像開發人員理解的通用語言。

乾淨的體系結構和類似/衍生的體系結構都具有相同的目標 -關注點的分離。他們引入將類似代碼捆綁在一起的層。 “分層”有助於我們在代碼庫中實現重要方面：

• 獨立於UI-業務邏輯與正在使用的UI框架（在這種情況下為Next.js）。可以在CLI應用程序中使用相同的系統，而無需更改業務邏輯或規則。
• 獨立於數據庫- 數據庫實現/操作是在自己的層中隔離的，因此應用程序的其餘部分不在乎使用哪個數據庫，而是使用模型進行通信。
• 獨立於框架- 業務規則和邏輯根本對外界一無所知。他們接收使用普通JavaScript定義的數據，使用普通的JavaScript，服務和存儲庫來定義自己的邏輯和功能。這使我們能夠將框架用作工具，而不必將我們的系統“塑造”到其實現和局限性中。如果我們在應用程序中使用路由處理程序，並且想重構其中一些用於服務器操作，那麼我們需要做的就是僅在服務器操作中調用特定的控制器而不是路由處理程序，但是核心業務邏輯保持不變。
• 可測試- 可以輕鬆測試業務邏輯和規則，因為它不取決於UI框架，數據庫，Web服務器或構建我們系統的任何其他外部元素。

乾淨的體系結構通過定義依賴性層次結構來實現這一目標 - 圖層僅取決於下面的層，但不取決於上面的層。

項目結構（僅重要的位）

• app框架和驅動程序層- 基本上所有Next.js（頁面，服務器操作，組件，樣式等）或任何“消耗”應用程序的邏輯的內容
• di依賴注入 - 我們設置DI容器和模塊的文件夾
• drizzle - 所有DB-初始化數據庫客戶端，定義模式，遷移
• src系統的“根”
  • application -應用程序層- 持有用例和界面，用於存儲庫和服務
  • entities -實體層- 保存模型和自定義錯誤
  • infrastructure -基礎架構層- 持有存儲庫和服務的實現，並從application中提取界面
  • interface-adapters -接口適配器層- 保存控制器，這些控制器是系統的切入點（在框架和驅動程序中用於與系統交互）
• tests - 單位測試現場 - unit文件夾的結構與src匹配
• .eslintrc.json​​
• vitest.config.ts注意@別名的定義方式！

層解釋

• 框架和驅動程序：保留所有UI框架功能，以及與系統相互作用的所有其他功能（例如AWS lambdas，Stripe Webhooks等...）。在這種情況下，這是Next.js路由處理程序，服務器操作，組件（服務器和客戶端），頁面，設計系統等...
  • 該層僅應使用控制器，模型和錯誤，並且不得使用用例，存儲庫和服務。
• 接口適配器：定義控制器：
  • 控制器將輸入傳遞給特定用例之前，請執行身份驗證檢查和輸入驗證。
  • 控制者協調用例。他們沒有實施任何邏輯，而是使用用例定義整個操作。
  • 較深層的錯誤被起泡並在使用控制器的地方處理。
  • 控制者使用演示者將數據轉換為對UI友好的格式，然後將其返回“消費者”。這有助於我們將JavaScript減少到客戶端（可轉換數據的邏輯和庫），有助於防止洩漏任何敏感屬性，例如電子郵件或哈希密碼，還可以幫助我們減少發送給客戶端的數據量。
• 應用：業務邏輯居住的地方。有時稱為核心。該層定義了服務和存儲庫的用例和接口。
  • 用例：
    • 表示單個操作，例如“創建todo”或“ sign in”或“ toggle todo”。
    • 接受預先驗證的輸入（來自控制器）並處理授權檢查。
    • 使用存儲庫和服務訪問數據源並與外部系統進行通信。
    • 用例不應使用其他用例。那是代碼的氣味。這意味著用例有多件事，應分解為多種用例。
  • 存儲庫和服務的接口：
    • 這些是在此層中定義的，因為我們想打破其工具和框架的依賴性（數據庫驅動程序，電子郵件服務等），因此我們將在基礎架構層中實現它們。
    • 由於接口生活在該層中，因此用例（以及上層層）可以通過依賴注入訪問它們。
    • 依賴注入使我們可以將定義（接口）與實現（類）分開，並將它們放在單獨的層（基礎架構）中，但仍然允許使用它們。
• 實體：定義模型和錯誤的地方。
  • 型號：
    • 使用普通JavaScript定義“域”數據形狀，而無需使用“數據庫”技術。
    • 模型並不總是與數據庫息息相關 - 發送電子郵件需要外部電子郵件服務，而不是數據庫，但是我們仍然需要具有數據形狀，以幫助其他層交流“發送電子郵件”。
    • 模型還定義了自己的驗證規則，該規則稱為“企業業務規則”。通常不會更改的規則，或者當某些東西更改時（頁面導航，安全等）時最不可能更改的規則。一個示例是一個User模型，它定義了一個用戶名字段，該字段必須至少為6個字符，而不包括特殊字符。
  • 錯誤：
    • 我們想要自己的錯誤，因為我們不想冒出特定於數據庫的錯誤或特定於庫或框架的任何類型的錯誤。
    • 我們catch來自其他庫（例如毛毛雨）的錯誤，並將這些錯誤轉換為我們自己的錯誤。
    • 這就是我們可以使核心獨立於任何框架，庫和技術的方式 - 乾淨體系結構的最重要方面之一。
• 基礎架構：在哪裡定義了存儲庫和服務。
  • 該層從應用程序層中拉出存儲庫和服務的接口，並將其實現在自己的類中。
  • 存儲庫是我們實施數據庫操作的方式。它們是揭示執行單個數據庫操作的方法的類 - 例如getTodo ， createTodo或updateTodo 。這意味著我們僅在這些類中使用數據庫庫 /驅動程序。他們沒有執行任何數據驗證，只需對數據庫執行查詢和突變，然後投擲我們的自定義定義錯誤或返回結果。
  • 服務是整個應用程序中使用的共享服務 - 例如身份驗證服務，電子郵件服務，或實施外部系統（例如Stripe（創建付款，驗證收據等）...）。這些服務還使用並取決於其他框架和庫。這就是為什麼他們的實施與存儲庫一起保存在這裡的原因。
  • 由於我們不希望任何一層取決於這一層（並且具有傳遞性取決於數據庫和所有服務），因此我們使用依賴性反轉原理。這使我們僅依賴於應用程序層中定義的接口，而不是基礎結構層中的實現。我們使用像ioctopus這樣的控制庫的反轉來抽象接口背後的實現，並在需要時“注入”它。我們在di目錄中創建抽象。我們將存儲庫，服務，控制器和用例“綁定”到符號，然後在需要實際實施時使用這些符號“解決”它們。這就是我們可以使用實現的方式，而無需明確依賴它（導入）。

常問問題

提示

如果您有一個常見問題解答未介紹的問題，請隨時在此存儲庫中打開問題，或者加入我的Discord Server並在那裡開始對話。

乾淨的體系結構 /此實現無服務器友好嗎？我可以將其部署到Vercel嗎？

是的！您可以將其與頁面路由器，應用程序路由器，中間件，API處理程序，服務器操作等一起使用！通常，使用iNversify.js庫在JavaScript項目中實現依賴項注入，這與節點除外的其他運行時間不兼容。該項目實現了IOCTOPUS，這是一個簡單的IOC容器，不依賴reflect-metadata並在所有運行時起作用。

創建下一個項目時，我應該立即開始實施乾淨的體系結構嗎？

我說不。如果您正在啟動一個全新的項目，我建議您專注於盡可能快地實現MVP狀態（因此您可以驗證您的想法 /查看項目是否有未來）。當事情開始變得嚴重時（更多功能開始實施，您的用戶群會體驗到顯著的增長，或者您正在登上項目中的其他開發人員），這就是您想花一些時間來調整此體系結構（或任何此事的任何體系結構）。

如果您已經在項目中的雜草深處，那麼您（和您的團隊）可以從下一個衝刺開始逐步進行重構。在這種情況下，您已經編寫了代碼，您只需要對其進行重新組織，然後可以部分地進行該代碼，以路由處理程序進行路由處理程序，通過服務器操作，服務器操作。順便說一句，我說“您只需要重新組織一點” ，但它遠非如此簡單。當您計劃重構時，請務必考慮“出錯”。並花一些時間進行編寫測試！

這看起來像是過度工程的，並且使特徵開髮變得複雜。

如果您不花超過3分鐘的時間考慮一下，那麼是的，它看起來確實是過度工程的。但是，如果這樣做，您將意識到架構=學科。該體系結構是開發人員之間的合同，可以定義去哪裡。它實際上簡化了功能開發，因為它使代碼庫可預測，並且為您做出這些決定。

如果每個從事它的開發人員都會在最方便的地方寫代碼，那麼您將無法可持續發展一個項目。代碼庫將變成與之合作的噩夢，這就是您會感到真正複雜的功能開發過程的時候。為了與之抗爭，最終您將放下一些規則。這些規則將隨著您的團隊面對並解決新問題而增長。將所有這些規則放在文檔中，並且有您自己的架構定義。您仍然實現某種建築，您剛剛非常緩慢而痛苦地達到了這一點。

乾淨的體系結構為您提供了經過測試的快捷方式和預定義的體系結構。是的，可以肯定的是，您確實需要學習所有這些，但是您一生都需要一次，然後將以後使用的任何語言或框架應用原則。

我應該在所有項目中應用乾淨的體系結構嗎？

不。如果您不希望該項目在功能數量，用戶數量或從事該項目的開發人員數量上都增長。

清潔建築的其他類似架構是什麼？

正如我在Readme頂部提到的原始博客文章中提到的那樣，您得到了：

• Alistair Cockburn的六角形建築（又名港口和適配器）
• Jeffrey Palermo的洋蔥建築
• 鮑勃叔叔的尖叫建築（乾淨建築背後的同一個人）
• 還有更多（查看原始博客文章）