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