如果你是一名業務開發，你可能要說，我整天就是做CRUD（增刪改查），哪裡需要了解什麼應用架構設計？
經常有人說，程式設計師 35 歲之後很容易陷入瓶頸，被行業淘汰，我覺得原因其實就在此。
有些朋友在寫程式碼的時候，可能沒有太多考慮非功能性的需求、擴充套件性，只是完成功能，覺得能用就好。做事情的時候，也沒有長遠的規劃，只是把眼前的事情做好就滿足了。
我面試過很多大齡候選人，他們的簡歷長達十幾頁，專案經歷有幾十個。然而，細看之下，每個專案只是重複堆砌業務邏輯，缺乏難度遞進，能力提升不明顯。
這樣的人，十年的積累可能與一年的積累無異。這樣的人，怎麼不會被行業淘汰呢？
隨著年齡增長，網際網路大環境也越來越卷，架構思維和設計知識是必須要掌握的。
應用架構是什麼？
應用架構定義了企業中的應用系統的結構和行為。它不僅僅是搭建幾個系統那麼簡單，更重要的是要考慮這些系統之間的關係，以及它們如何協同工作，以滿足業務需要。
透過應用架構，我們可以清晰地識別出支援業務和資料處理所需的應用系統，並實現從業務需求到IT系統的轉化。
一個優秀的應用架構，能讓系統既穩定，又能靈活擴充套件和升級，快速應對市場需求變化。
應用架構的設計步驟一般包括：
- 基於業務架構，完成業務到IT系統的轉換，識別核心應用服務。
- 劃分應用結構，設計應用結構與業務流程，資料的關係。
- 設計應用結構間的互動、整合關係。
應用服務
應用服務在應用架構中起著至關重要的作用，它將系統的核心功能打包，並提供給外部使用，可以視為系統對外的“門面”，使用者或其他系統透過呼叫應用服務來實現特定的業務功能。
從外部視角來看，應用服務通常是帶有明確的業務含義，比如下單、支付、查詢庫存等。這些服務的設計必須緊密圍繞業務需求，確保能夠高效地支撐業務流程的執行。
應用服務的概念源於SOA和微服務架構的興起。透過將系統功能拆分為多個獨立的服務，可以提高系統的可維護性、可擴充套件性和靈活性。
應用服務的概念源自於面向服務的架構（SOA）和微服務架構的興起。透過將系統的功能模組化為多個獨立的服務，不僅提升了系統的可維護性，還增強了系統的擴充套件性和靈活性。每個服務可以獨立開發、部署和升級，這樣即使業務需求發生變化，也只需調整相關服務，而無需大幅修改整個系統。
面向服務的架構最大的價值就在於它的敏捷性和靈活性。
敏捷性體現在服務可以快速調整，獨立演化。靈活性則體現在每個服務都有清晰的業務邊界，功能內聚性強，能夠單獨管理生命週期。
透過服務的組合和編排，系統可以快速響應業務的變化，支援複雜的業務流程，構建起一個既穩固又靈活的技術基礎設施。
應用結構
應用結構描述了應用系統內部的層次結構和組織關係，它決定了系統的模組化程度，以及後續的開發和維護難度。
在應用結構設計中，我們通常會把系統抽象為不同的層次。比如，將系統劃分為系統級、應用級、模組級和程式碼級。
這種抽象級別的劃分幫助我們在不同層面處理複雜性，確保系統結構清晰且易於維護。如圖所示：
- 系統級：關注的是各個系統的整體佈局和治理方式，比如各個系統之間的關係，以及它們如何協同工作。
- 應用級：聚焦於各個應用的整體架構，包括應用與其他應用的互動方式，以及各個應用在整個系統中的角色。
- 模組級：對應用內部的進一步細化，它涉及到程式碼的模組化設計、資料和狀態的管理等。透過合理的模組劃分，可以提高程式碼的可維護性、可重用性，減少重複勞動。
- 程式碼級：關注的是程式碼本身的結構和實現方式。這一層級的設計直接影響到程式碼的質量和實現細節。
抽象級別的存在，主要是為了幫助我們更好地管理系統的複雜性。
1.分解複雜度
如果將所有的細節混雜在一起，整個系統將變得難以理解、維護和擴充套件。透過設定不同的抽象級別，我們可以將系統的複雜性分解到各個層次，每個層次只需關注特定的功能和職責。
這種分層處理方式使開發人員在專注於系統某一部分時，無需過多關注其他部分的細節，從而大大簡化了系統的設計和開發過程。
2.團隊協作邊界清晰
在大型專案中，通常會有多個團隊並行開發。如果系統沒有明確的邊界，各團隊之間很容易產生衝突和重複勞動。
透過清晰的抽象級別劃分，不同團隊可以專注於系統的不同層次或模組，互不干擾。
3.擴充套件性強
隨著業務需求的變化，系統往往需要不斷地擴充套件和升級。如果系統的架構設計沒有合理的抽象級別，擴充套件和升級就會變得異常困難，甚至可能引發系統的全面重構。
而在有抽象級別的系統中，變更往往只需要聚焦在特定的層次上進行，而不會影響整個系統。例如，一次業務改造隻影響模組級別，我們可以在不改變系統整體架構的情況下，替換或新增某個模組，以滿足新的業務需求。
應用互動
應用互動是指不同應用系統或元件之間的資料交換和通訊方式。
在一個複雜的系統中，各個應用並不是孤立存在的，它們往往需要相互協作，才能完成更復雜的業務流程。
應用互動的設計就是為了確保這些系統和元件能夠順暢地“對話”，實現系統整體功能。
應用互動的形式有多種，包括同步呼叫、非同步訊息傳遞、事件驅動等。每種互動方式都有其特定的應用場景和優缺點。
例如，同步呼叫通常用於那些需要即時響應的場景，使用者在前端提交訂單後，系統會立即呼叫訂單服務建立訂單，這種方式的優點是可以保證請求的實時性，但也要求系統的各個部分在呼叫時都能正常工作。
相對的，非同步訊息傳遞則適用於那些不需要即時響應的場景，比如訂單建立後，訂單服務可以將訂單建立的訊息傳送到訊息佇列，而履約服務可以在適當的時候處理這條訊息。這種方式的優勢在於能夠提高系統的解耦性，避免系統在高負載時，因為同步呼叫導致效能瓶頸。
透過合理的互動設計，系統中的各個部分能夠高效協同，減少耦合度，增加系統的靈活性。同時，良好的互動設計還能顯著提升系統的效能和容錯能力，即使在大流量訪問、業務需求複雜的情況下，也依然保持穩定執行。
寫在最後
應用架構定義了企業應用系統的結構和行為，強調系統間的關係和協同工作。
透過應用架構，可以識別支援業務和資料處理的系統，實現從業務需求到IT系統的轉化。設計步驟包括業務到IT系統的轉換、應用結構設計及其互動關係。
應用服務是系統的核心功能模組，源於SOA和微服務架構，提升了系統的可維護性和靈活性。
應用結構則描述了系統的層次結構，幫助管理複雜性，促進團隊協作和系統擴充套件。應用互動設計確保系統元件間的資料交換和通訊方式高效，提升系統效能和容錯能力。