在微服务中，为数据库迁移脚本和 API 代码建立单独的代码存储库是否有意义？

Question

根据有界上下文，我们已经确定了两个微服务实现，我们分别调用它们Service A和Service B。每个微服务都有不同的存储库（由于单一职责和更好的所有权的好处）。现在，每个存储库都使用自己的数据库架构（选择是为了更好地分离持久性并减少数据库实例的维护）。

之前，我们将数据库迁移脚本（用于持续交付）提取到单独的单个存储库（包含 和Service A模式Service B的脚本）中，并在 CI 下的单个作业下运行它们。现在，当我们处理更多的故事时，我们开始面临一些挑战，其中一些挑战如下：

• 对单个模式的更改会触发整个数据库的构建，从而触发所有微服务的下游，从而增加我们的反馈时间
• 我们通常无法实现true持续交付，因为架构更改也需要相应的代码更改Service，因此部署两个PR时都需要谨慎
• 此外，还有一些公共表Users需要由两个模式使用，这些表目前正在两个模式之间复制。

所以我的问题/疑问是：

• 我们是否应该根据模式分离数据库迁移存储库，就像服务一样。
• 我们是否应该为数据库迁移脚本建立单独的存储库？我们应该将它们合并到各自的Service存储库代码中吗？
• 我们是否应该进一步提取通用表a level up并筹集Domain Events资金Eventual Consistency

任何指示/建议都会有很大帮助。谢谢。

Answer 1

您应该考虑将迁移保留在相应的代码存储库中。服务 A 应该有自己的一组独立于服务 B 的迁移。这将允许您部署服务 A 并迁移 A 的架构，而不会对服务 B 产生任何影响。

另外，您应该考虑没有公用表。公用表可能有严重的缺点。如果服务 A 需要以破坏服务 B 的方式修改用户，那么您就创建了一个分布式整体。

更新1：

构建审核日志可能不需要很强的引用完整性。您可以考虑使用软外键。

微服务的设计方式很大程度上依赖于领域。如果 aUser是经过身份验证的用户，那么您应该首先解决身份验证的横切问题。您可以选择让每个微服务需要身份验证令牌（例如 jwt）来确定经过身份验证的用户是谁以及他们是否有权执行某些操作。然后您可以简单地使用审核日志中的用户 ID。

至于用户是否“属于服务的有界上下文”，很可能不会。换句话说， update against 如何User绑定到Service A？您可能不认为该用户从属于服务 A，也不想通过针对服务 A 的操作来更新用户。