join - 微服务和领域逻辑连接

部署微服务托管自己的数据库。

当业务需求需要跨多个服务中的数据进行联接时，您会采用什么策略？

示例问题:您正在实现一个电影评论网站。您有一个保存电影数据库的电影微服务。您还有一个评论微服务，可以在其自己的单独数据库中管理评论。评论通过 GUID 链接到电影；但由于它们是作为单独的数据存储实现的，因此不是关键约束。

您希望获得一份精确到最后一刻的报告，告诉您每个评论级别的评论总数，按评论字数 > 25 个单词的电影的第一个字母分组。您目前对 40,000 部电影发表了 500 万条评论。

E.G.超过 25 个字的评论:

为您的项目选择微服务架构后，您现在将采用什么策略来实现此功能？

最佳答案

我想此时我会问自己，您尝试建模的领域到底是什么。如果域严格渲染电影和电影评论，我的问题是为什么有两个单独的服务:电影和电影评论服务。

本质上，我会将这两个服务合并为一个服务，并将其称为电影评论服务，因为电影的评论才是我们所关心的。在这种情况下，连接就不再有问题。

我个人认为真正要问的问题是电影服务是否应该存在以及它扮演什么样的角色。在您的示例中，分解为单独的服务似乎是无关紧要的。虽然这可能不是一个令人满意的答案，但所提供的示例在技术上有点过于简单，无法使微服务架构变得有值(value)，因为需要分离关注点以真正将它们进一步分解为多个服务的组件较少。

如果示例足够复杂，足以保证微服务架构拥有这两个单独的服务，那么这只是电影评论服务和电影服务中数据冗余的问题，以便完全非规范化。这个想法是，服务应该尽可能完全依赖自身，而不是向非常细粒度的服务发出多个请求，从而导致反模式——纳米服务架构。希望这有帮助!

关于join - 微服务和领域逻辑连接，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32831192/