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

Question

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

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

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

所以我的问题/疑问是：

• 我们是否应该像服务一样根据架构分离数据库迁移存储库。
• 我们是否应该为数据库迁移脚本设置单独的存储库？我们是否应该在他们各自的Service 存储库代码中加入它们？
• 我们是否应该进一步提取公用表a level up 并为Eventual Consistency 提高Domain Events

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

Answer 1

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

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

---

更新 1：

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

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

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