重要要點
- 值得關注的新軟件架構趨勢包括微前端，數據網格，AsyncAPI和策略即代碼。各種各樣的目的表明，創新正在建築景觀的許多不同領域中發生。
- 隨着微服務變得越來越普遍，從微服務架構開始的阻力越來越大。越來越多的公司正在考慮正確構建分佈式系統或創建現代的模塊化整體的基礎，以爲將來可能需要將其分解爲微服務。
- GraphQL顯然已經跨越了這個鴻溝，唯一的爭論是它被廣泛採用。在擴展GraphQL並將其普遍應用於大型企業方面仍存在創新。
- 對低代碼/無代碼平臺的興趣日益濃厚，它可以使非開發人員能夠定製系統。
- 跟蹤的幾個體系結構概念僅適用於某些情況。因此，他們在採用曲線上沒有自然發展的趨勢。示例包括功能編程和事件驅動的體系結構。
創新者 早期採用者 早期主流用戶 成熟主流用戶
良好的軟件體系結構的目標是幫助管理複雜的系統。爲了響應分佈式系統，事件驅動的體系結構和大數據，軟件體系結構的最新創新希望能夠利用正在出現的最佳實踐，還可以幫助指導工程師擺脫常見的陷阱。
InfoQ軟件體系結構和設計主題圖重點介紹了主要的軟件體系結構概念及其在行業中的當前採用狀態。InfoQ和QCon都集中在圖表的左側，涵蓋了創新者和早期採用者之間的軟件趨勢狀態。我們還將尋找最終會“跨越鴻溝”併爲大多數公司所接受的想法。
創新者
創新者中的四個新趨勢包括微前端，AsyncAPI，數據網格和策略即代碼。
微型前端
微前端旨在將微服務的相同優勢帶到UI層。通過將複雜的系統分解爲更小，更易於管理的部分，團隊可以快速開發和發佈新功能。
在出現在InfoQ Podcast中之後，我們聯繫了Building Micro Frontends的作者Luca Mezzalira，對他對未來一兩年的期望提出了自己的想法。
盧卡·梅扎里拉（Luca Mezzalira）：微型前端並不是新趨勢，但它們在2019年獲得了關注。
仍然有很多最佳實踐可供發現，社區非常活躍。在過去的8到10個月中，我們製作了新的框架，技術和文檔，使微型前端對所有開發人員而言都更加易於使用。
我不認爲微型前端將成爲前端開發的靈丹妙藥，但是我確實相信它是單頁面應用程序和服務器端渲染體系結構的絕佳補充。
當我們在大型業務領域中與數十名開發人員一起工作的項目時，微前端會發光，我們希望通過劃分爲多個子域來降低複雜性，獨立部署應用程序的不同部分，而不會在團隊之間造成通信和協調開銷。
幾個組織開始接受它們，我希望在2020年能看到更多的案例研究，以解釋這些公司如何採用該範式以及遇到了哪些PRO和CON。
我相信，到2020年，微型前端將成爲一種既定的體系結構，並且會被前端社區理解。我不希望微型前端能用於所有的前端項目，但是有很多公司可以真正從這種體系結構範例中受益。
異步API
AsyncAPI解決了靜態 API與事件驅動的體系結構和事件源之間的不一致。微服務的採用日益廣泛，導致更多公司實施了EDA，這也帶動了EDA的發展。但是，這些改進需要從同步的請求/響應API過渡到專門爲異步通信而構建的API。
丹尼爾·布萊恩特（Daniel Bryant）表示，他“在客戶聊天中偶然聽到了這一消息。幾乎所有采用Swagger / OpenAPI的人都在看類似AsyncAPI的東西。”
數據網格
ThoughtWorks的Zhamak Dehghani在一篇文章中首先討論了數據網格的概念。引人深思的概念是，通過擁抱面向領域的數據所有權，可以避免傳統數據倉庫或整體數據湖的陷阱。
托馬斯·貝茨（Thomas Betts）表示：“過去我們沒有跟蹤數據架構，但是我有興趣看看這是否遵循了將整體式細分爲微服務以提高大數據系統敏捷性的趨勢。”
InfoQ向Dehghani詢問了她對Data Mesh的當前和未來狀態的看法。
Zhamak Dehghani：互聯分權是我們數字經濟，社會和組織發展的潛在趨勢。在過去的十年中，諸如雲，微服務，API，容器化和域驅動設計之類的技術已使運營世界的分散化成爲可能。但是，不幸的是，數據世界已被集中式的過時範式所支配。數據網格是對分析數據管理失敗模式的直接響應，旨在超越組織，使其成爲數據驅動的，並與相關的分散化趨勢保持一致。
在接下來的一兩年中，我希望看到更多地採用Data Mesh，並共享更多的實施案例研究。我希望許多早期的實現將創建自定義的工程工具和技術，我希望這將導致開源工具的發展或雲提供商產品的擴展，以滿足Data Mesh的技術需求。
我看到業界的問題是什麼是Data Mesh，在新的一年中將更改爲How to do Data Mesh，當然，隨着採用率的增長，接下來的幾年中將如何更改Data Mesh。
鑑於Data Mesh需要圍繞數據所有權和治理進行組織變革，因此在高層管理人員和領導層的大力支持下，面向工程的組織才能真正實現這一範例。
政策即代碼
我們還在管理軟件開發生命週期方面看到了創新。作爲代碼的策略是將結構置於所需系統狀態周圍的顯着趨勢之一。這建立在將基礎結構作爲代碼的思想之上，併爲體系結構級別帶來了類似的好處。在KubeCon和雲廠商中，科比看到了Code所談論的Policy 。
早期採用者
無服務器
總是引發健康討論的一個主題是無服務器。InfoQ編輯認爲無服務器還沒有解決這個問題，並且也有人反對這種想法。這與對微服務的抵制有關，因爲越來越多的團隊意識到無服務器和微服務體系結構並不是要解決每個問題的正確解決方案。
這導致了關於正確構建的分佈式系統和模塊化整體的健康討論。
Jan Stenberg觀察到在最近的DDD Europe會議上討論的無服務器和分佈式系統：
Stenberg：對我來說有趣的一點是Gojko Adzic 談論了無服務器，並且非常熱情，但他指出，即使是非常簡單的“ Hello World”應用程序也是高度分佈式的。這將需要熟練的開發人員；這會影響無服務器的成本效益嗎？
Vladik Khononov 建議閱讀 1970年由Glenford J. Myers寫給所有對微服務感興趣的人的Composite / Structured Design。他說，儘管本書沒有提及微服務一詞，但本書中討論的基本設計原則與微服務相同。
Stenberg還認爲模塊化單片應添加到早期採用者中：
Stenberg：提到了Kamil Grzybek，Randy Shoup等人，也提到了Stefan Tilkov，後者在2015年聲稱很難構建模塊化的整體，因此建議在需要時使用微服務。
但這有點奇怪。怎樣構建一個設計良好的模塊化應用程序才能成爲“早期採用者”？是否有類似“新生代”的早期採用者？
謙虛：有了無服務器，我認爲它沒有越過鴻溝，我實際上看到了一些反對它的傳聞。我認爲這是對微服務（或更確切地說，人們意識到微服務並非解決每個問題的答案）的更廣泛的反對–我們在QCon London上就該主題進行了演講。我認爲這很可能會保留一些小衆方法。我們認爲我們應該跟蹤/談論整體的迴歸嗎？
布萊恩特：我最初確實想知道“無服務器”是否越過了鴻溝，但我認爲沒有。有很多報告（例如）表明了該領域的巨大增長機會，這也使我認爲它仍然處於Early Adopter中。
貝茨：一年前，人們談論的是構建完全無服務器的系統，而且這種炒作已經減少。諸如AWS Lambda或Azure Functions之類的單個無服務器功能可能已經跨越了鴻溝，但是完全無服務器的架構還沒有，而且可能永遠不會獲得廣泛採用。
低碼和無碼
低代碼和無代碼解決方案有望將更多功能交付最終用戶，而無需開發人員參與。儘管業內資深人士可能對供應商的推動力持懷疑態度，但使用這些平臺的開發人員試驗已經明顯增加。
謙虛：我在低代碼平臺上有點憤世嫉俗。我認爲這主要是供應商的推動，也是我以前見過的。話雖如此，我希望看到更多開發人員嘗試使用低代碼平臺，部分原因是Microsoft重新推出了其PowerApps，Flow，Power BI和Power Platform產品的推動。我還發現Google收購AppSheet很有趣。這些平臺正在成爲大生意，我認爲這是我們應該關注的趨勢。
Betts：（輕量級）工作流程和決策自動化平臺應保留在Early Adopter中。這與低代碼/無代碼平臺有很強的相關性，對於主題圖而言，這可能是一個更好的通用術語。這些平臺針對的是非開發人員，因此是在購買中，而不是在基礎上發展。挑戰圍繞着集成，而不是圍繞一個平臺構建主要系統。
Stenberg：低代碼使我想起了我的年輕同事，他們在90年代的大學裏只因爲過時的OO而教過4GL。
我看不到現代工作流程引擎（如Zebee）屬於低代碼（但它們可能屬於“工作流程和決策自動化平臺”）。他們正在處理核心業務工作流程，您想讓域知道您的核心業務正在平穩運行，並且您不想通過監視來發現問題。
GraphQL
GraphQL顯然已經跨越了這個鴻溝，但是InfoQ編輯者的問題是它屬於早期多數還是晚期多數。儘管將GraphQL作爲一種技術的使用已達到後期多數，但我們仍在看到創新，其中GraphQL影響圍繞可伸縮性的體系結構決策並在整個系統中創建凝聚性語言。
謙虛：我認爲GraphQL堅定地跨越了鴻溝。Dylan在最新的網絡趨勢報告中將其列爲“多數後期” 。
貝茨：我認爲GraphQL已經跨越了鴻溝。採用的級別已將其從僅在API層實現的東西帶到了系統設計的中心方面。這可能與TypeScript的採用最爲相似，因爲在這種情況下，團隊認識到在整個系統中使用強類型構造的好處。
軟件構架倫理
科比提出了一個問題，我們是否應該在這個隊列中跟蹤道德。“我越來越多地在SACON和QCon上看到道德操守會議和履歷。” 我們最終決定不在此主題圖上包含道德規範，因爲它可以在“ 軟件文化和方法”主題圖上得到更好的體現。
Humble指出QCon和InfoQ多年來一直在討論道德問題：
謙卑：我認爲我們傾向於將倫理學視爲文化話題，但這是跨領域的。我們絕對應該繼續對此進行跟蹤並進行報告。我爲能在QCon London和相應的eMag的道德操守上迅速完成這項工作而感到自豪，並且我認爲鑑於每個人的生活中普遍存在的軟件，繼續討論它非常重要。
貝茨認爲道德是建築師作爲技術負責人的一個方面：
貝茨：雖然我爲人們對道德規範的認識和討論有所增加感到鼓掌，但我不確定在A＆D主題圖表上是否需要提及道德規範。但是，我確實認爲技術領導者必須考慮道德的許多方面，並且我希望看到一些有關A＆D中道德考慮的InfoQ文章。我一直認爲，在這方面提供指導的最好的人是真正瞭解它的實踐者。沒有積極的領導，設計最終將變得被動，並被迫遵守不可避免的政府法規，例如GDPR和CCPA。
其他話題
圖表的其餘部分基本上保持不變。響應式編程，HTTP / 2和gRPC跨越了這個鴻溝，但是所有其他項目都沒有動。對於A＆D來說，這是可以預期的，與編程語言趨勢相比，好的創意需要更長的時間才能成熟，並且壽命更長。
作爲參考，下面顯示了2019年初的主題圖。2020版是本文的開頭。
