通用數據模型和微服務集成

Question

由於所需的原生雲應用或微服務架構分散的數據模型（每個微服務都有自己的數據庫），並universal data model是集中式的數據模型

那麼，我們如何與通用數據模型微服務架構模式？

是否有任何通用數據模型和微服務的參考或實現？

Answer 1

總的來說，這兩種概念不兼容。對所有服務使用通用數據模型會與使用微服務背後的一些關鍵想法相沖突，例如， Polyglot Persistence，單獨開發&部署每個服務。此外，我們不要忘記，「數據模型資源手冊」上次於2009年

然而，如果必須將二者結合起來的方法，例如更新由於管理層堅持要求，您可以通過專用服務封裝對通用數據模型的所有訪問，並使其他服務依賴於它。

關於這個問題的一些善念可以在這裏找到：http://plainoldobjects.com/2015/09/02/does-each-microservice-really-need-its-own-database-2/

Answer 2

是以@弗裏茨的觀點 - 通用數據模型和微服務真的是兩個不同的概念，是非常困難的，如果不是不可能一起使用。我想補充一點，polyglot持久性的推理也是因爲應該如何建模數據。微服務允許使用不同的數據存儲，這些數據存儲可以根據域進行最佳的數據建模。

爲了更詳細地闡述，我認爲提到微服務和數據建模而不是域驅動設計是公平的。根據我的經驗，領域驅動設計確實有助於思考服務，其責任和存在的權利。例如，我發現通常情況下，通常會有一組服務執行特定的域功能。一個例子可以是具有付款，購物車等的電子商務應用程序。這些應用程序可以基於域驅動的設計術語被分成不同的「有界的上下文」。

隨着不同的限界上下文，每個微服務不再看到系統中的同一相同的概念，因此，實際上，沒有真正的通用數據模型。我能想到的最簡單的例子就是當您還想要報告系統中的指標時。如果示例是電子商務應用程序，則訂單microservice中的事務概念將與報告服務中的事務不同。例如，報告服務可能想要了解某個子級別的交易，例如特定訂單所產生的利潤或收入，而不是訂單中的特定訂單項。但是，從訂單服務角度來看，訂單詳細信息（如訂單項和進行購買的個人地址）可能很重要，應該知道。這應該需要兩個不同的數據模型。

對於域建模，我可能有點偏激，但我會去遠的話說，如果有多個服務共享同一數據源，他們真的應該是相同的服務;對於單個數據源應該只有一項服務。我的理由是該域未被正確建模，並且如果存在多個依賴於單個數據源的服務，則耦合使得它不同於演進任何一個服務。情況可能是一個服務需要數據源的模式改變，而另一個服務不需要，但仍然需要適應模式更改。希望這可以幫助！