所以我有一个架构，有几个不同的 "后端 "asp.net核心web api's.我使用Masstransit和rabbitmq来促进容器间的通信。我使用Masstransit和rabbitmq来促进容器间的通信。使用MassTransit，服务之间需要一种合同（只是简单的类），如果系统部署在本地或服务器上，这是很好的，但对于docker容器，这已被证明是一个问题。
我试着上网查了很多资料，但似乎很少有asp.net core，尤其是masstransit，结合docker的文档。
所以问题是。
我怎样才能让用asp.net core写的容器分开，共享消息合约（即模型类）？
我想过创建一个nugget包。这将工作，但它似乎是一个非常不优雅的解决方案+合同将是公共的（不是一个大问题，但仍然可能不是很大）。
最后，我用docker-compose来协调服务--如果这和你的答案有关系的话。
如果项目在不同的GitHub仓库中，你需要共享合同，你有几个选择。
创建一个单独的仓库，以NuGet包的形式发布。你可以私下进行，使用GitHub包仓库，这样你的合同就不会出现在公共的NuGet站点上。这给了你一个单一的地方，但却成为消息合同的单一争夺点。好：它很简单，而且合同 不该 变化，新版本的设计应该是向后兼容的，因为不是所有的服务都会升级到最新版本。
将类（虽然我个人更喜欢接口，但这是另一个故事）复制到你的项目中--确切地说，包括命名空间。有些强迫症患者会对此感到抓狂，但说实话，我们对JSON和HTTP做了什么不同的事情吗？如果合同管理得好，并且所有者在确保它们一致和兼容方面表现出了控制力，这就可以了。而且我已经看到了它的工作。不过，我还是要重复一下。命名空间非常匹配，而不仅仅是类接口的名称。.
这是我用过的两种方法，都很成功。我听说有些团队使用一个单独的仓库，每个服务都有文件夹。这很有道理，现代CICD可以跟踪路径变化，并且只对修改后的服务进行builddeploy。所以我想这是第三种选择，而不是为紧密耦合的服务创建无数个存储库。