簡單地說，API主導的連接方法可以被看作是API設計的一種分層方法（至少在本文中是這樣）。其中，系統API公開系統的資產數據信息；中間的是流程API，與系統API一起進行編排和組合；頂端的體驗API公開來自后端數據源的數據，提供最終用戶體驗。這種API分層方法與細粒度SOA模式很好地結合在一起，通常，這兩者要么可以共存，要么細粒度SOA模式演化成基于細粒度SOA的分層API模式。
API主導的連接方法為細粒度SOA模式提供了一些層次結構，這些層次結構允許對API或微服務進行一致的管理和治理。然而，基于細粒度SOA的分層API模式也存在一些與細粒度SOA 模式類似的深層問題（這很直觀）：
在細粒度SOA模式執行單個API調用的地方，基于細粒度SOA的分層API模式現在必須通過層執行多個調用。從“網絡跳數”的角度來看，這種模式可能是低效的。但是，基于細粒度SOA的分層API模式中，層次結構的存在并不強制跨越網絡來調用每個API。直接的跨層調用，而不是通過網絡調用是完全有效的；分層的目的是為了增加靈活性，同時以一種很好地分離關注點的方式構建體系架構。
在細粒度SOA模式管理大量服務的地方，使用分層API將會管理來自多個層次的大量細粒度服務。您的管理工具可能不再像以前那樣有效，因為它們可能無法可視化復雜的微服務視圖。
最終應用程序的數據存儲一致性在分層API模式下實際上得到了改善，因為訪問數據的服務都是有組織，且集中地查詢或修改應用程序的狀態。（例如：系統API）
實際上，對于大多數企業來說，基于細粒度SOA的分層API模式是一個很好的模式，但是，就像細粒度SOA模式一樣，在實踐過程中會出現困難。然而，這種困難通常在大范圍使用時才會顯現出來。因此，只有在預期或正在經歷大規模的使用時，我們才應該準備其他的模式。
問題：
沒有一定層次結構的微服務架構是很難進行合理解釋的，因為沒有明顯的方法來對每個微服務的用途進行分類和可視化。
解決方案：
通過創建按用途分組的分層API（系統層、流程及領域模型層，以及體驗層），您可以更容易地管理微服務架構的復雜性。
應用：
將微服務架構分為多個層。通常情況下，可以使用標準化，并具有類似用途的一組微服務以類似的方式工作，從而進一步使微服務架構的復雜性合理化。
影響：
1.通過標準化和進一步分解微服務架構，可以提高快速變更的能力。
2.由于更專門化的層次結構，進程間服務調用的數量可能增加。
3.需要對服務監控和可視化工具進行檢查，以確定它們是否能夠正確地與分層架構一起工作。
目標：
1.快速的敏捷變更。
2.可伸縮性：理論上通過基于細粒度SOA的分層API模式可以提高可伸縮性，但實際上，除非有支持自動化的基礎設施，否則可伸縮性往往會降低。
主要特點：
1.為了實現快速變更，可能存在低效的IPC（Inter-Process Communication，進程間通信）。
2.數據一致性和狀態管理能力較差，但允許高度重用。重用本身會抵消變更的速度。
3.由于與現存模式的相似性，已有的問題往往同樣會出現。
4.基于細粒度SOA的分層API模式在小范圍內使用效果很好，在大規模情況下會出現困難。
5.由于采用了結構化的體系架構方法，所以具有很高的內聚性。
6.重點放在服務顆粒度要細，但通常沒有考慮其能力。
7.基于細粒度SOA的分層API模式以集成為導向，每個微服務依賴于外部系統。這將會降低變更的速度。
基于細粒度SOA的分層API模式如何與SOA或API等現有系統共存？
基于細粒度SOA的分層API模式往往是與現有IT資產共存的最佳方式。由于分層減少了每個微服務的范圍，并約束了其用途，因此該模式能夠在不明顯降低變更速度的情況下，最好地連接和利用現有IT系統。然而，通過細粒度和分層的設計來協調變更可能是一個挑戰。您可能需要使用一定的技術手段來管理所有不同微服務之間的契約，或者使用完全自動化的測試技術來確保變更不會造成破壞。
