DDD 存储库的查询语言答案

【问题标题】：Query language for DDD repositoryDDD 存储库的查询语言
【发布时间】：2018-04-04 04:48:00
【问题描述】：

目前我正在努力将单体 REST api 拆分为微服务。我要介绍Domain Driven Design（正在学习中）。我目前最关心的是实现Repository。

域 UBIQUITOUS LANGUAGE 定义 Profile 实体（社交媒体资料，例如 Twitter 资料）。我正在考虑提取Profile 以分离微服务。要查询个人资料，我会介绍ProfileRepository。

包括 API 网关在内的其他微服务有自己的 Profile 搜索模式。我应该如何设计存储库以满足所有这些搜索模式。我应该为每个查询创建find 方法吗？我应该引入某种动态查询语言吗？

在单体架构中，我可以创建多个存储库。每个用例一个。在微服务架构中，每次其他微服务需要新查询时，我都需要更改负责 Profile 的微服务。

【问题讨论】：

没有什么是完美的。如果您的查询机制过于抽象，它将是灵活的，但很难优化性能。另一方面，如果您的查询都非常明确，那么微服务之间的耦合可能太强了。我认为您可以考虑的一种方法是使用基于消息的基础架构来复制在所有其他微服务中处理查询所需的信息。如果这不合适，那么您将不得不尝试在灵活性、性能和明确性之间取得良好的平衡。

标签： domain-driven-design microservices

【解决方案1】：

添加动态查询语言会引入另一个级别的复杂性，我个人的看法是，除非你真的非常需要它，否则你应该避免这种情况——即当其他人要大量集成你的系统时。我非常同意 @plalx 对您帖子的评论 - 增加复杂性总是有代价的，这是双向的。

关于无处不在的语言和术语组合 - 您确实应该避免在您的域中出现重复的术语。有关社交媒体帐户的“个人资料”可以命名为“SocialProfile”。因此，当“个人资料”在两种不同的上下文中意味着两种不同的事物时：尝试为其中一种找到更好的术语。当然，您可以知道“API 网关”上下文中的“个人资料”是某种东西，同时在其他上下文中它是其他东西，但是从长远来看，这对您没有好处 - 尝试将新人添加到项目并解释您称之为“个人资料”的不同事物。

关于你的最后一个问题：

在单体架构中，我可以创建多个存储库。每个用例一个。在微服务架构中，每次其他微服务需要新查询时，我都需要更改负责 Profile 的微服务。

这真的取决于您的架构 - 您的微服务是否使用相同的代码库和存储库类？它们甚至在同一个名称空间中吗？您可以为每个微服务使用一个存储库，这是合乎逻辑的方法，因为您的不同微服务会做不同的事情。如果您接受我的建议并为您的域中的每个实体找到具体的术语，您将不必对此感到疑惑。 :)

我的实践中关于 REST API 的旁注：如果您的 API 是真正的 REST，您可以只使用每个端点后面的存储库。但是，如果您发现您的 API 端点不仅在读取和返回数据（或实体），而且还在“做某事”，那么需要注意两点： - 你的 API 很可能不是 REST，而是普通的 RPC - 您在端点后面使用的对象很可能是服务而不是存储库

【讨论】：

我同意您关于将 Profile 命名为 SocialProfile 的第一个声明。我尽量不在微服务之间共享相同的代码库。每个微服务都有自己的源存储库。它允许我在不改变其他人的情况下引入其他实用程序微服务。我的目标是在单个微服务中访问 SocialProfile 的数据库。其他微服务将使用其 API 来访问 SocialProfiles。