构建nservicebus解决方案的最佳方式是什么？

我们正在开发用于用户管理的IT服务和人力资源服务，但我们在确定项目结构的最佳方式时遇到了困难

一位开发人员认为IT项目和HR项目应该在subversion中分开，我们应该对每个消息项目使用SVN外部

另一个开发人员认为，我们应该将它们放在同一个subversion项目中，但通过使用all.sln、hr.sln和it.sln将它们按文件夹拆分来对服务进行分区

---

划分这些服务边界的最佳方法是什么？

这听起来像是一个典型的循环依赖问题。对于我们来说，了解It服务是否依赖于人力资源服务很重要，反之亦然，或者两者之间是否需要双向沟通。如果一个依赖于另一个，那么我的建议是有两种解决方案。假设这取决于人力资源。然后在HR中，您可能有一个核心项目来定义域对象和接口，包括需要表示为消息的事件或命令。Core没有依赖项—它不引用NServiceBus或解决方案中的任何其他项目。在同一个解决方案中，您可能有一个参考Core的HR.Infrastructure项目。在此范围内，您可以定义消息，以便它们继承核心的事件和命令，并实现NServiceBus.IMessage（从而引用NServiceBus）。现在，它可以简单地引用HR.Core和HR.Infrastructure来处理消息

---

如果需要双向通信，那么您只需要将消息拉到它们自己的解决方案/项目中，并让两个基础架构项目都依赖/引用它。您不应该让您的核心项目引用它，因为这将从您的核心创建到NServiceBus的依赖链，这是您想要避免的。如果这看起来很奇怪，请继续阅读，看看这是如何做到的。

我对Subversion不太熟悉，但通常我们所做的是在构建后将服务之间的依赖关系签入源代码管理，然后在构建后分支到各自的服务中。这样做的原因是允许每个服务独立决定何时采用较新版本的共享依赖项。通过使用分支操作，您就拥有了依赖关系的完整历史记录，并且可以随时回滚。这还使您能够使用相同依赖项的不同版本发布服务。在服务的后续分支中，您可以拥有不同版本的依赖关系

在这种情况下，您将签入消息程序集并将它们分支（或合并）到每个服务中。从那里，您可以根据需要获取新版本