目前我正致力于将monolith REST api拆分为微服务。我想介绍Domain Driven Design（目前正在学习）。我现在最关心的是实施Repository。
Domain UBIQUITOUS LANGUAGE定义Profile实体（社交媒体资料，例如Twitter个人资料）。我想提取Profile以分离微服务。要查询个人资料，我会介绍ProfileRepository。
其他微服务包括API网关都有自己的Profile搜索模式。我应该如何设计Repository以满足所有这些搜索模式。我应该为每个查询创建find方法吗？我应该介绍某种动态查询语言吗？
在monolith架构中，我可以创建多个存储库。每个用例一个。在微服务架构中，每当其他微服务需要新查询时，我就需要更改负责Profile的微服务。
答案 0 :(得分：1)
添加动态查询语言会引入另一层次的复杂性，我个人认为除非你真的真的需要它，否则你应该避免这种情况 - 即当其他人要集成你的系统时。我非常同意@plalx对你的帖子的评论 - 增加复杂性总是有它的价格，而且两方面都有。
关于无处不在的语言＆amp;术语组合 - 您应该真正避免在您的域中重复使用术语。关于社交媒体帐户的“简档”可以被命名为“SocialProfile”。因此，当“个人资料”在两个不同的背景下意味着两个不同的事情时：尝试为其中一个找到更好的术语。当然，你可以知道'API网关'环境中的'配置文件'是某种东西，同时它在其他环境中是另外的东西，但是从长远来看这对你不利 - 尝试添加新人到项目并解释你称之为“个人资料”的不同事物。
关于你的上一个问题：
在monolith架构中，我可以创建多个存储库。每个用例一个。在微服务架构中，每当其他微服务需要新查询时，我就需要更改负责Profile的微服务。
这实际上取决于您的架构 - 您的微服务是否使用相同的代码库和存储库类？他们甚至在同一个名字空间吗？您可以为每个微服务使用一个存储库，这是合乎逻辑的方法，因为您的不同微服务将执行不同的操作。 如果您接受我的建议并为您域中的每个实体找到具体条款，您将不必怀疑这一点。 ：）
我的实践中关于REST API的附注： 如果您的API是真正的REST，您可以使用每个端点后面的存储库。但是，如果您发现您的API端点不仅仅是阅读和返回数据（或实体）但也“做某事”然后有两件事需要注意： - 你的API最可能不是REST而是普通的RPC - 您在端点后面使用的对象是最可能的服务而不是存储库