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

Question

我们正在为用户管理目的开发IT服务和人力资源服务，但我们无法确定构建项目的最佳方式。

一个开发人员认为IT项目和人力资源项目应该在颠覆中分开，我们应该将SVN外部用于每个消息项目吗？

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

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

Answer 1

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

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

Answer 2

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

如果需要进行双向通信，那么您只需将消息提取到他们自己的解决方案/项目中，并让两个基础结构项目都依赖/引用它。你不应该让你的Core项目引用它，因为这会从你的Core创建一个NServiceBus的依赖链，你想要避免。如果这看起来很奇怪，请阅读Onion Architecture和Dependency Inversion Principle以了解如何完成此操作。