組件庫也可以成為從一開始就開發更干凈、更耐用、更有彈性的代碼庫的秘密成分。在您職業生涯的某個階段，您無疑遇到過DRY 代碼的概念 – 該縮寫詞代表“不要重復自己”。下面，我們將探討干凈代碼的一些原則，以及為什么它們對 API 如此重要。我們還將了解兩種常見的開發工作流程以及每種工作流程的優缺點。
一位導師曾經告訴我，“所有代碼在 15 分鐘后都是遺留代碼。”編寫干凈代碼的最佳理由是留下一些遺產，在您繼續前進后對其他人有用 – 即使只是在您繼續吃午餐時。對于 API 開發人員來說，這意味著編寫易于在 API 雙方（生產者和消費者）工作的其他開發人員使用的代碼。
強調干凈的代碼非常適合實用的API 即產品心態；如果您認為這只是極客性能優化專家的領域，那么您就忽略了該方法的一些關鍵優勢。將您的 API 程序視為一流產品意味著不斷監控使用情況、集成新技術并不斷滿足新的用戶需求。頻繁的迭代需要代碼足夠高效以支持可觀察性并且足夠有彈性以適應變化。
那么什么是干凈的代碼呢？ DRY 首字母縮略詞是一種常見的簡寫形式，但這只是一個起點。另一個可以給你一些更清晰方向的縮寫詞是SOLID 。正如您將在下面看到的，這也是一種特別適用于 Stoplight 組件庫的方法：
無論您嚴格遵守 SOLID 原則，還是只是努力遵循更簡潔代碼的一般實踐，目的都是構建一個能夠隨著時間的推移而持續存在的 API 程序。當然有可能走得太遠——批評者警告說，毫無疑問地使用“干凈代碼”實踐會降低性能——這就是為什么我們強調需要正確看待原則。持久的產品需要滿足真正的用戶需求，但也需要經過精心設計以承受這些需求的變化。任何代碼標準方法的目標都應該是彈性和靈活性，使未來的開發人員能夠繼續有效地為您的 API 消費者提供服務。
在設計新的 API 程序時，沒有絕對的最佳實踐。正如我們上面所說，原則和實踐應該服務于您的產品目標，而不是決定您的方法。那么您應該從哪里開始 API 設計過程呢？有兩個主要選項，每個選項代表 API 的“相反”端：
一些純粹主義者堅持認為，領域驅動方法是確保應用程序架構真正干凈、沒有潛在問題的依賴項并且隨著時間的推移保持穩定的唯一方法。
正如您可能已經猜到的，我們將稍微推遲這一點。有些推理是合理的——在項目開始時建立共享的術語和定義是關鍵的一步，而創建準確、靈活的數據模型顯然很重要，無論從哪里開始。但實現這些好處并不需要領域驅動的方法，而且如果您等待太長時間才評估 API 用戶的需求，您可能會錯過寶貴的信息。
API 設計優先是一種與API 優先產品策略理念密切相關的開發方法。 API 優先首先將您的 API 視為一流產品，重點關注定義和滿足消費者需求。設計優先將原則轉化為實踐，通過迭代定義 API 程序必須實現的結果并仔細描述它將如何交付這些結果的細節。開發過程首先確定用戶需要的數據以及該數據的最佳形狀，然后繼續進行。
眾所周知，我們堅信 API 優先的開發。該方法可以在整個設計和開發過程中創造更高的效率，并可以通過更少的試驗和錯誤實現更持久的集成。由于您的團隊首先考慮現實世界的用例，因此實際的安全問題從一開始就會引起關注。您可以盡早考慮移動使用情況和指標要求等因素，確保您的 API 設計滿足發布時所需的技術規范。 API 是為恰好是開發人員的消費者提供的產品；設計 API 時要考慮到開發人員的需求，這是一項經過充分檢驗的業務策略。
盡管基于消費者需求進行設計很重要，但值得注意的是，API 優先的方法可能并不總是能產生組織良好的架構。 API 優先的方法可能會導致混亂的代碼以及貧乏的領域模型。在某種程度上，這是因為從消費者端開始的設計流程往往關注端點和方法，并有很多拼湊在一起的事務腳本。開發人員構建控制器方法，將數據操縱成承諾端點所需的形狀。此過程可能會生成大量具有不必要的復雜性和重復性的命令式代碼。雖然 API 優先的設計并不一定會導致混亂，但防止混亂需要仔細的規劃和協調。
與 API 優先設計相比，領域驅動設計優先考慮內部資源的知識和功能。前提是，從準確有效地表示核心業務概念的數據架構開始，同時確保內部利益相關者的支持，您可以降低 API 的整體復雜性。
理論上，DDD 將導致更多的聲明性代碼更容易閱讀，從而更容易維護。在開發的初始階段定義數據模型的形狀、功能和關系可以增加生成干凈、干燥代碼的機會。當您最終進入創建控制器方法和 API 端點的階段時，它們將由模型的形狀決定，并且會以反映數據中表示的現實世界實體的方式自然地就位。
在實踐中，對領域專業知識的狹隘關注可能會導致模型不夠靈活，無法服務于現實世界的用例，特別是當焦點完全集中在內部上下文時。 “不要發布組織結構圖”這句格言是一個警示，說明以領域為中心的團隊傾向于創建反映他們的偏見而不是產品消費者需求的產品。這正式稱為“康威定律” ，它會對產品質量產生嚴重后果。在整個 API 設計過程中需要有意識地努力避免陷阱。
DDD 也可能很慢，并且在開發的相當后期之前，您幾乎無法根據 API 消費者的期望進行測試。如果您試圖將新服務或產品快速推向市場，或者您的技術挑戰超過了數據挑戰，那么嚴格的領域驅動方法可能會成為障礙而不是幫助。
那么，當我們為新的 API 程序選擇設計流程時，這會給我們帶來什么影響呢？看來，雖然這兩種方法都不完美，但都具有很大的潛在價值。
組件庫允許您創建單個標準數據模型并在多個 API 之間共享它，因此您可以采用領域驅動設計中的關鍵概念：
使用組件庫可以幫助您實現 DDD 的優勢：更簡單的通信、提供更大靈活性的堅實基礎，以及清楚數據形狀在何處決定其他設計選擇。
API 設計優先的開發策略。這種方法帶來了一些重要的好處：
組件庫在整個產品生命周期中支持高質量的 API 程序。它們充當您的領域知識的存儲庫，使您能夠以易于使用、可共享的格式記錄內部資源和業務功能的專業知識。當您使用 API 設計優先策略時，由于組件庫與 OpenAPI 工具集成，因此可以輕松地通過模擬將設計中的數據轉移到開發中。無論從哪里開始，您都可以使用 DRY、SOLID 代碼和一流的開發人員經驗來構建 API。
有關 API 設計流程和工具的任何決策都應由您的獨特需求和實際情況驅動。沒有一個單一范例可以服務于每個 API 程序或開發團隊。組件庫的優點是它們不會強迫您采用教條方法——無論您采取什么策略，這個工具都可以幫助您實現精心構建的領域層和以用戶為中心的設計過程的好處。
原文鏈接：Build?Cleaner,?DRYer?APIs?with?Component?Libraries