因此，我们的开发团队在过去的6-8个月里一直致力于微服务，并且已经获得了很多动力。
在那段时间里，我们经历了几个gotcha时刻，并且随着我们越来越接近将平台投入生产，我们已经知道我们还有更多的时间。
我无法完全理解的一个方面是我们如何在服务边界之间处理数据。我听到很多大公司已成功实施微服务的声明，但我似乎永远无法得到直接的建议和推理。
具体而言，给定两个服务域User和Contacts，并假设User有一个Contact对象与之关联，有哪些选项可供选择这两个服务域中的每一个都有关于管理自己的数据的信息吗？
User是否应该存储ContactID，还是应该存储整个Contact对象？
我见过许多可靠的面向服务的开发团队（Netflix，亚马逊，耐克等）做出如下声明：
“正常化是所有邪恶的根源......”
“打破共享的所有内容......”
“别分享......”
答案 0 :(得分：0)
那些陈述是错误的。模块化就是为您的环境找到低耦合和高内聚的正确组合。用户可以存储联系对象的副本，只要它知道它只是某个特定时刻的快照。对于许多用例很好，有时您只需要确保使用负责域名的真实联系人。
答案 1 :(得分：0)
保持主数据规范化。但是 - 如果您有类似“ContactID”的内容，则会错误地规范化您的数据！
规范化实体必须不是表格而是商业实体 - 具有商业意义的文档。为什么需要ContactID？如果您有联系人公司列表，请保持公司内部的联系人。如果您希望联系人在公司和合同之间共享信息 - 请通过电子邮件或公司名称或任何其他对业务有意义的字段返回联系信息。
完全非规范化数据用于从主数据构建的派生数据。它主要用于构建索引以进行搜索和排序。
答案 2 :(得分：0)
通过共享身份（ID）来跨服务边界关联数据是完全正确的。
当您的UI需要显示来自两个服务的相关数据时，而不是在服务之间复制数据（这与您所听到的松散耦合的微服务粒度相反），您可以使用客户端组合来组装运行时客户端上的数据。从两个服务中获取数据，构建组成它的ViewModel，然后在屏幕上显示它。将它组合在一起的逻辑不需要耦合到任何一种服务。它可以获取服务返回的任何数据并动态组合。执行客户端组合的服务有时被称为＆＃34; IT / Ops服务。＆＃34;
这是一个如何在技术上完成的例子：