通用数据模型和微服务集成
Universal data model and microservices integration
由于原生云应用或微服务架构需要去中心化数据模型（每个微服务都有自己的数据库），universal data model是中心化数据模型
那么，我们如何拥有具有通用数据模型模式的微服务架构？
有通用数据模型和微服务的参考或实现吗？
总的来说，这两个概念不兼容。为所有服务使用通用数据模型会与使用微服务背后的几个关键思想发生冲突，例如Polyglot Persistence，每个服务的单独开发和部署。另外，我们不要忘记 "Data Model Resource Book" 最后一次更新是在 2009 年。
但是，如果您必须结合这两种方法，例如因为管理坚持它，你可以通过专用服务封装对通用数据模型的所有访问，并使你的其他服务依赖它。
关于这个主题的一些好的想法可以在这里找到：http://plainoldobjects.com/2015/09/02/does-each-microservice-really-need-its-own-database-2/
同意@Fritz 的观点——通用数据建模和微服务实际上是两个不同的概念，即使不是不可能一起使用也非常困难。我想补充一点，多语言持久性的原因也是因为数据应该如何建模。微服务允许使用不同的数据存储，这些数据存储可以根据其领域对数据进行最佳建模。
为了详细说明，我认为只提及微服务和数据建模而不是域驱动设计是不公平的。根据我的经验，领域驱动设计确实有助于思考服务、它们的责任和它们存在的权利。例如，我发现通常存在执行特定领域功能的服务集合的情况。一个示例可能是具有支付、购物车等功能的电子商务应用程序。这些可以根据领域驱动设计术语分为不同的 "bounded contexts"。
随着限界上下文的不同，每个微服务不再在系统中看到相同的概念，因此实际上没有真正通用的数据模型。我能想到的最简单的例子就是当你还想报告系统中的指标时。如果示例是电子商务应用程序，那么订单微服务中的交易概念将不同于报告服务中的交易。例如，报告服务可能想了解子级别的交易，例如为特定订单而不是订单中的特定行项目产生的利润或收入。但是，从订单服务的角度来看，订单详细信息（例如行项目和进行购买的个人的地址）可能很重要，应该知道。这应该需要两个不同的数据模型。
关于领域建模，我可能有点极端，但我什至可以说，如果有多个服务共享同一个数据源，它们实际上应该是同一个服务；一个数据源应该只有一个服务。我对此的论点是，领域没有被正确建模，如果有多个服务依赖于一个数据源，那么耦合使得任何一个服务的发展都不同。情况可能是一种服务需要更改数据源的架构，而另一种服务不需要但仍然需要更改以适应架构更改。希望这对您有所帮助！
由于原生云应用或微服务架构需要去中心化数据模型（每个微服务都有自己的数据库），universal data model是中心化数据模型
那么，我们如何拥有具有通用数据模型模式的微服务架构？
有通用数据模型和微服务的参考或实现吗？
总的来说，这两个概念不兼容。为所有服务使用通用数据模型会与使用微服务背后的几个关键思想发生冲突，例如Polyglot Persistence，每个服务的单独开发和部署。另外，我们不要忘记 "Data Model Resource Book" 最后一次更新是在 2009 年。
但是，如果您必须结合这两种方法，例如因为管理坚持它，你可以通过专用服务封装对通用数据模型的所有访问，并使你的其他服务依赖它。
关于这个主题的一些好的想法可以在这里找到：http://plainoldobjects.com/2015/09/02/does-each-microservice-really-need-its-own-database-2/
同意@Fritz 的观点——通用数据建模和微服务实际上是两个不同的概念，即使不是不可能一起使用也非常困难。我想补充一点，多语言持久性的原因也是因为数据应该如何建模。微服务允许使用不同的数据存储，这些数据存储可以根据其领域对数据进行最佳建模。
为了详细说明，我认为只提及微服务和数据建模而不是域驱动设计是不公平的。根据我的经验，领域驱动设计确实有助于思考服务、它们的责任和它们存在的权利。例如，我发现通常存在执行特定领域功能的服务集合的情况。一个示例可能是具有支付、购物车等功能的电子商务应用程序。这些可以根据领域驱动设计术语分为不同的 "bounded contexts"。
随着限界上下文的不同，每个微服务不再在系统中看到相同的概念，因此实际上没有真正通用的数据模型。我能想到的最简单的例子就是当你还想报告系统中的指标时。如果示例是电子商务应用程序，那么订单微服务中的交易概念将不同于报告服务中的交易。例如，报告服务可能想了解子级别的交易，例如为特定订单而不是订单中的特定行项目产生的利润或收入。但是，从订单服务的角度来看，订单详细信息（例如行项目和进行购买的个人的地址）可能很重要，应该知道。这应该需要两个不同的数据模型。
关于领域建模，我可能有点极端，但我什至可以说，如果有多个服务共享同一个数据源，它们实际上应该是同一个服务；一个数据源应该只有一个服务。我对此的论点是，领域没有被正确建模，如果有多个服务依赖于一个数据源，那么耦合使得任何一个服务的发展都不同。情况可能是一种服务需要更改数据源的架构，而另一种服务不需要但仍然需要更改以适应架构更改。希望这对您有所帮助！