故事：
- 我们有很多
microservices，通信主要通过发送serialized DTOs通过Service Bus进行 - 一些微服务
share the DB，所以实体models，目前在每个微服务中都是duplicated
问题：
- 每当我们想要用于微服务之间通信的
modify DTO时，我们都需要modify it in each microservice - 任何一个
change in the shared DB都需要做changes in all related microservices，而单个DB字段编辑会导致multiple PRs
可能的解决方案：
将任何共享代码移动到其他存储库(DTO repo、实体模型repo等)，并使用Class Library projects创建解决方案。
在这一点之后，我有两种方法：
- 创建
NuGets并将其添加到微服务中 - 添加
bare Class Library projects作为所有微服务的参考，我们将获得带有微服务的Multi-repo solutions
优点/缺点：
对于NuGets，我看到的主要缺点是：
- 它将需要一些围绕它构建的
extra infrastructure来创建工件 To test any change需要修改Nuget Solution，触发一些CI管道和wait to build the NuGet本身，用NuGet的测试版本更新微服务，然后我们才能测试微服务本身- 如果出现
any errors-repeat an entire process
对于bare Class Library projects，我看到的主要优势是：
VS 2022带来了一些不错的support for Multi-repo解决方案- CCD_ 26和CCD_
问题：
- 你能为我的
possible solutions添加一些优点/缺点吗 - 你能推荐其他解决问题的方案吗(有优点/缺点)
不是你的问题的答案，至少是一个完整的答案，但需要考虑的事情很少：
我建议从更深入的角度来研究单存储库与多存储库的优缺点，这已经讨论了很多次(例如在这里或这里)，所以请先阅读这些文章。
每当我们想要修改用于微服务之间通信的DTO时，我们都需要在每个微服务中对其进行修改。
在通常情况下，使用正确的设计和版本控制方法，您不需要在每次更改时修改每个微服务中的DTO(如果该更改与该微服务无关)，除非它是一个破坏性更改，并且破坏性更改应尽可能少地进行，并且应通过版本控制进行处理。
你可以尝试研究的另一件事是使用模式注册表来定义共享合同，并通过git子模块将其添加到每个项目中，并编写某种生成器来自动构建DTO。
共享数据库中的任何更改都需要更改所有相关的微服务，并且单个数据库字段编辑会导致多个PR。
我认为微服务架构中的共享数据库是一个巨大的反模式，应该尽快解决(是的，我知道生活并不总是理想的，也不总是与模式一致)，修复它将消除你当前的很多问题，所以我建议集中精力(如果可能/可行的话)，而不是解决症状。
此外，您还可以考虑以某种方式复制.NET团队正在转移到.的VMR
至于"；裸类库项目；以及VS多回购支持-首先，目前的多回购支持仅限于10个回购，并不是每个人都在使用VS(例如，因为它在Linux ATM上不可用)，其次，还有一个问题是设置构建服务器来处理它(使用nuget会更容易)。
要测试任何更改，需要修改Nuget Solution，触发一些CI管道并等待构建Nuget本身，用Nuget的测试版本更新微服务，然后我们才能测试微服务本身。
您可以创建一个本地nuget源，并将本地打包的nuget放入其中。
只是要注意nuget缓存。如果你想更新你的nuget包，并且仍然使用相同的版本，你应该先从http-cache中删除它。位置可以通过dotnet nuget locals --list http-cache或NUGET_HTTP_CACHE_PATHenv变量获得。