微服務與多層架構
我的項目有一個後端服務（Web API）和一個前端 SPA 應用程序。後端服務具有位於不同 .net 程序集中的表示層、應用程序服務、域和基礎設施層。領域層有業務領域對象、基礎設施——與外部數據和其他東西的通信、應用程序服務——表示層使用的一組服務、表示——Web API 控制器。我認為這是非常常見的分層架構。
我們的新架構師宣布我們將把後端遷移到微服務架構，分解我們的層，將域、應用程序服務和基礎設施層劃分為幾個服務，並將表示層轉換為前端層的後端（如此處所述）。在功能方面，我們將有移動應用程序。Sql Server 數據庫現在將保持原樣。
我沒有微服務架構的經驗，所以我的問題是：多層架構已經過時了嗎？這樣的架構設計能給我的應用帶來什麼好處和問題？
微服務和分層架構有點不同。微服務架構是關於你的應用程序是如何建構的，它有哪些組件（服務）以及這些服務如何相互通信，它們是如何開發、部署的等等。
多層架構是將應用程序邏輯劃分為層，其中每一層都有自己的邏輯功能（表示、域等）。很多時候，多層架構與單體架構和服務設計有關。
根據您的描述，您不會分解您的層，您的架構師希望將邏輯拆分為不同的服務。這兩種架構風格可以一起使用。例如，您可以有 3 個服務，每個服務都可以有表示層、域層和服務層。如果您目前在一項服務中的層足夠重，那麼將它們分開以使開發和測試更容易是有意義的。前端風格的後端也有它的好處，特別是如果你想添加一個移動應用程序。
對這個
多層架構已經過時了嗎？
不，它們都被使用，但作為規則，微服務層應該比單體應用程序薄得多。
這樣的架構設計能給我的應用帶來什麼好處和問題？
我建議您查看微服務和單體架構風格之間的比較以及這篇文章。要劃分與否，您應該考慮項目的規模和復雜性，以及團隊的規模。劃分必須為整個應用程序帶來好處，使開發更容易。Monolithic 應用程序有其自身的優勢，並且在項目規模達到一定規模時，它可能是一個不錯的決定。當然，與龐大的單體應用程序以及一百個非常小的（納米）服務一起工作是一場噩夢。