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

Question

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

一个开发认为，IT项目和人力资源项目应在颠覆分开，我们应该使用SVN的外部给每个项目的消息？

其他开发人员认为我们应该只是把它们放在同一个颠覆项目，但具有分区服务的all.sln，hr.sln，并通过it.sln文件夹分裂他们。

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

Answer 1

我不是太熟悉的颠覆，但通常我们所做的是确实有服务签入源代码控制生成后，再经过分流到各自的服务之间的依赖关系。这样做的原因是为了让每个服务独立决定何时采用新版本的共享依赖关系。通过使用分支操作，您可以获得完整的依赖关系历史记录，并且可以随时回滚。这也使您能够使用不同版本的相同依赖项来发布您的服务。在您的服务的后续分支中，您可以拥有不同版本的依赖关系。

在这种情况下，你会检查，在消息组件和分支机构（或合并）他们到每个服务。从那里你可以根据需要采取新的版本。

Answer 2

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

如果需要有双向通信，那么你只需要拉出来的消息到自己的解决方案/项目，并同时拥有基础设施项目依赖/引用它。你不应该让你的Core项目引用它，因为这会从你的Core创建一个NServiceBus的依赖链，你想避免它。如果这看起来很奇怪，请阅读Onion Architecture和Dependency Inversion Principle以了解如何完成此操作。