關注留言點贊，帶你了解最流行的軟體開發知識與最新科技行業趨勢。
戰略結合了流程、原則和模式。這是一項需要組織承諾的艱巨任務。學習一種協調的、跨領域的方法。
設計應用程式架構永遠不會完成。定期地，所有決策群組件都需要審查、驗證并可能進行更新。利益相關者要求更快地傳遞複雜的應用程式。即使對于最資深的技術人員來說，這也是一個挑戰。需要一種政策，而且它需要靈活。戰略結合了有助于保持團隊專注的流程，以及為實施提供最佳實踐的原則和模式。無論如何，這是一項需要組織承諾的艱巨任務。
開發、設計和架構流程
沒有任何過程開發的應用程式是混亂的。發明自己的流程并堅持使用的團隊比不使用流程的團隊要好得多。同時，将項目作為流程的人質可能同樣有害。最佳實踐和模式是經過多年的團隊開發的，他們正在尋找更好的方法來及時生成高品質的軟體。流程是最佳實踐和模式的編纂。通過将最佳實踐和模式編入流程，流程可以擴充到更多的組織和團隊。
例如，當組織選擇開發過程時，進階上司可能會歸因于測試先行的開發模式。通過找到概述模式如何在組織上實施的流程，組織采用模式變得更加容易。在測試先行開發模式的情況下，可以選擇測試驅動開發（TDD）作為開發過程。
同一組織中的另一位技術上司者可能會選擇使用領域驅動設計 (DDD) 來上司他們的團隊，這是一種在技術團隊和其他利益相關者之間交流軟體設計的模式。這兩種設計理念可以共存嗎？是的。他們能。在這裡，TDD 定義了軟體的建構方式，而 DDD 定義了描述軟體的 概念。
軟體架構對特定的開發和設計過程保持中立，它是關于如何實作抽象模式的規範。之是以使用術語“抽象模式”，是因為大多數軟體架構模式都可以應用于任何開發過程和任何技術堆棧。例如，許多架構都采用了控制反轉（或依賴注入）。Java、JavaScript、C# 等如何實作控制反轉是特定于技術堆棧的，但它們實作了相同的目标。
避免教條式的堅持
無論開發、設計或架構過程如何，關鍵是嚴格遵守給定過程不會成為最終目标。不幸的是，這種情況經常發生。請記住，流程的目的是以一種允許團隊使用相同的目标和目标進行擴充的方式來規範最佳實踐。
為此，在實施流程時，需要考慮以下幾點：
- 沒有一種尺寸适合所有人。
- 讓文化塑造流程。
- 成熟需要時間。
- 專注于您真正在做的事情——及時建構高品質的軟體。
交叉問題
軟體體系結構可以通過多種方式進行設計、表達和實作。無論采用何種方法，大多數軟體架構計劃都解決兩個關鍵點：簡單性和演進性。簡單性是一個相對術語，因為架構方法需要在業務領域的上下文中易于了解。團隊成員應該檢視架構計劃并說：“當然，這是顯而易見的設計。” 制定計劃可能需要幾個月的時間，但以這種方式響應的團隊表明計劃走上了正确的軌道。進化非常重要，并且可能是建築計劃中最棘手的方面。這聽起來可能很難，但一個建築計劃應該能夠持續十年以上。這可能很難了解，但有了正确的設計原則和模式，它并不像人們想象的那樣具有挑戰性。
就其核心而言，良好的軟體架構會盡力避免将自己逼入絕境。下面的圖 1 沒有包含新的啟示。然而，每一點對于持久的軟體架構都是至關重要的：
- 建造經久不衰的建築。這是最終目标。它需要使用支援其餘點的模式。
- 多平台和部署支援。這裡的關鍵是，今天存在的東西很可能在五年後看起來會有所不同。無論未來在哪裡，應用程式都需要能夠随時适應平台和部署模型的變化。
- 可執行的标準模式和合規性。并不是說沒有什麼新鮮事，而是軟體行業有數十年的模式可供采納和合規性舉措需要遵守。兩者的變化都是漸進的，是以密切關注地平線很重要。
- 從頭開始重用和可擴充性。重用和可擴充性的實施模式會有所不同，但這些要點多年來一直是建構塊。
- 與獨立的外部子產品協作。微服務時代有助于強化這一原則。注意複雜的內建。這是架構的危險信号。
- 進化、子產品相容性和更新路徑。軟體架構中的一切都會發展。考慮如何管理相容性和更新。
- 過時的設計。了解軟體架構中的許多元件最終将需要完全替換。在每個項目或裡程碑的開始，問這樣一個問題：“我們從這個版本中删除了多少代碼？” 定期代碼修剪的效果與修剪植物的效果沒有什麼不同。
圖 1：主要架構原則
開發微服務是遵循這些關鍵架構原則以及将元件劃分為責任區域的組合。微服務提供一個業務功能單元。單獨來看，它們為企業提供的價值很小。它是在與其他微服務的組裝和內建中實作業務價值的。
良好的微服務組裝和內建實作遵循多層方法。
水準和垂直切片
簡而言之，切片應用程式就是将事物保留在它們所屬的位置。除了遵循代碼庫中的相關設計模式外，對應用程式進行切片還會在應用程式級别應用相同的模式。考慮下圖中 Lego® 積木結構所描繪的應用程式架構：
圖 2：微服務架構
積木的每一部分都被那薄薄的樂高®積木隔開，表明每一層之間的職責嚴格分離。層僅通過提供的合同/接口進行互動。圖 2 描繪了三個層，每個層都有不同的用途。無論是與筆記本電腦或平闆電腦等裝置內建，還是與其他微服務內建的微服務，接收服務請求的點在邏輯上都是相同的。這裡有幾個入口點，從 Web 服務和消息服務到事件總線。
水準切片
應用程式架構的水準切片是層，從底部開始，每一層都為下一層提供服務。通常，堆棧的每一層都會細化底層服務的範圍以滿足業務用例邏輯。下層服務無法假設上層服務如何與它們互動。如前所述，這是通過定義明确的合同完成的。
此外，層内的服務通過該層的契約互相互動。嚴格遵守合同允許每一層的元件被新的或增強的版本替換，而不會中斷互操作性。
圖 3：水準切片
垂直切片
垂直切片是一切都聚集在一起的地方。垂直切片提供應用程式業務目标。垂直切片從貫穿整個架構的入口點開始。如圖 4 所示，可以通過多種方式公開業務服務。入口點通常通過某種類型的網絡協定公開。
但是，在某些情況下網絡協定是不夠的。在這些情況下，業務服務可能會提供支援直接內建的本機庫。無論用例如何，都必須嚴格遵守合同。
圖 4：垂直切片
顯而易見，但具有挑戰性
微服務已成為組裝大型應用程式的主要模式。每個微服務都涉及一組非常具體的功能。就其本質而言，微服務要求有明确定義的契約，其他微服務和系統可以與之內建。為雲原生部署設計和實施的微服務可以利用雲原生基礎設施來支援所讨論的幾種模式。
此處呈現的模式和圖表對大多數人來說是顯而易見的。如前所述，好的架構是“顯而易見的”。挑戰在于堅持它。通常，堅持的最大敵人是時間。滿足交貨期限的壓力是真實存在的，合同中也出現了裂痕。鑒于多種因素在起作用，有時需要做出妥協。做筆記、建立工單、添加評論并留下蹤迹，以便盡快解決妥協問題。
設計良好的應用程式架構與良好的流程相結合，可以支援長期使用，從業務角度來看，這提供了極好的投資回報。建立項目的機會少于改進現有應用程式的機會。無論如何，把這一切都承擔起來可能看起來很吓人。關鍵是從某個地方開始。作為一個團隊，制定一個計劃并“做到這一點”！