我们有一个由传统整体Web应用程序使用的数据库，该数据库开发人员团队经常更改该数据库。其他开发团队的任务是将该旧版 Web 应用的大量功能提取到 ASP.NET Core 2.1 WebApi 微服务中。每个微服务都使用该数据库和"数据库优先"方法。因此，我们的微服务中有很多模型。但是遗留的 Web 应用程序过着自己的生活，它的数据库经常被数据库开发人员修改。因此，它正在打破我们的微服务模型。我们不能使用迁移，因为它会破坏我们暂时无法关闭的旧版 Web 应用程序。
因此，我们决定使用"模型优先"方法和自定义 SQL 视图，该方法在自定义 EF Core 2.1 QueryType 和数据库表之间实现此类协定。因此，如果数据库开发人员将更改数据库表，例如删除列或更改列类型或类似内容，他们将收到一条消息，告知存在该列的视图，因此您不能简单地删除它。这种方法为我们提供了这样的保护级别，用于修改微服务模型中使用的架构部分。
因此，由于业务需求，旧版 Web 应用程序及其数据库肯定应该能够被修改。因此，具有数据库的旧式整体式 Web 应用程序是先例。但是这些修改正在破坏我们的微服务模型，但我们当然不希望它。
处理此类场景的最佳实践是什么？
这是一个很好的问题，这个问题经常出现。
一种选择是文化：实施代码审查流程，其中数据库开发人员需要创建拉取请求，并且无法推送/合并数据库修改脚本和/或执行发布，而无需应用程序开发人员的至少 2 个批准。
如果数据库开发人员不通过版本控制循环更改，和/或他们不愿意认识到您的需求，和/或他们不愿意在文化和流程更改过程中合作(正如优秀的敏捷/DevOps奉献者应该做的那样(，那么是的，您将需要考虑其他选择。
我认为你真正遇到的是两个开发团队之间缺乏沟通，这是一个更难解决的问题。如果你有来自任何一个团队的开发人员随机运行SQL脚本，那么你总是会遇到问题。
一个不错的技术解决方案是将集成测试作为 CI/CD 管道的一部分进行维护。将更改签入数据库项目时，还要对任何受影响的微服务应用程序运行生成和测试。
失败的测试会立即为微服务开发人员发出危险信号，甚至可能阻止将更改转移到主分支中。