构建 nservicebus 解决方案的最佳方法是什么？
我们正在开发用于用户管理的 IT 服务和 HR 服务，但我们在决定构建项目的最佳方式时遇到了困难。
一位开发人员认为 IT 项目和 HR 项目应该在颠覆中分开，并且我们应该在每个消息项目中使用 SVN 外部？
另一位开发人员认为我们应该将它们放在同一个 subversion 项目中，但通过 all.sln、hr.sln 和 it.sln 按文件夹分割服务来对服务进行分区。
划分这些服务边界的最佳方法是什么？
We're in the process of developing an IT service and a HR service for the purposes of user management, but we're having trouble deciding the best way to structure the projects.
One dev believes the IT project and HR project's should be separated in subversion and that we should use SVN externals to each Messages project?
Another dev thinks we should just put them in the same subversion project but partition the services by having an all.sln, hr.sln, and it.sln splitting them by folders.
What is the best way to partition these service boundaries?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我对 Subversion 不太熟悉，但通常我们所做的是将服务之间的依赖关系签入源代码控制构建后，然后分支到各自的服务中。这样做的原因是允许每个服务独立决定何时采用更新版本的共享依赖项。通过使用分支操作，您可以获得依赖关系的完整历史记录，并且可以随时回滚。这还使您能够使用同一依赖项的不同版本来交付服务。在服务的后续分支中，您可以拥有不同版本的依赖项。
在这种情况下，您将签入消息程序集并将它们分支（或合并）到每个服务中。从那里您可以根据需要获取新版本。
I'm not too familiar with Subversion, but typically what we have done is do have dependencies between services checked into source control post build and then branched into their respective service after. The reason this is done is to allow each service to independently decide when to take a newer version of a shared dependency. By using a branch operation then you have full history of the dependency and can roll back at any time. This also gives you the ability to ship your service with different versions of the same dependency. In subsequent branches of your service you can have varying versions of the dependency.
In this case you would check-in the messages assemblies and branch(or merge) them into each service. From there you can take new versions as required.
这听起来像是一个经典的循环依赖问题。对于我们来说，了解 IT 服务是否依赖于 HR 服务，或者 IT 服务是否依赖于 HR 服务，或者两者之间是否需要双向沟通非常重要。如果一个依赖于另一个，那么我的建议是采用两种解决方案。假设 IT 取决于 HR。然后，在 HR 中，您可能有一个核心项目，用于定义域对象和接口，包括需要表示为消息的事件或命令。 Core 没有依赖项 - 它不引用 NServiceBus 或解决方案中的任何其他项目。在同一解决方案中，您可能有一个引用 Core 的 HR.Infrastruct 项目。在此范围内，您可以定义消息，以便它们继承自 Core 的事件和命令，以及实现 NServiceBus.IMessage（从而引用 NServiceBus）。现在，IT 可以简单地引用 HR.Core 和 HR.Infrastruct 来处理消息。
如果需要双向通信，那么您只需将消息提取到自己的解决方案/项目中，并让两个基础设施项目依赖/引用它。您不应该让您的 Core 项目引用它，因为这会创建从您的 Core 到 NServiceBus 的依赖链，这是您想要避免的。如果这看起来很奇怪，请阅读 洋葱架构 和 依赖倒置原则看看这是如何完成的。
This sounds like a classic circular dependency problem. It's important for us to know whether the IT service depends on the HR service, or vice versa, or if there is a need for two-way communication between the two. If one depends on the other, then my recommendation is to have two solutions. Let's say IT depends on HR. Then in HR you might have a Core project that defines your domain objects and interfaces, including Events or Commands that need to be represented as messages. Core has no dependencies - it does not reference NServiceBus or any other projects in your solution. Within the same solution, you might have an HR.Infrastructure project, that references Core. Within this, you can define your messages, such that they inherit from Core's Events and Commands, as well as implementing NServiceBus.IMessage (and thus referencing NServiceBus). Now IT can simply reference HR.Core and HR.Infrastructure in order to deal with messages.
If there needs to be bidirectional communication, then you simply need to pull the messages out into their own solution/project, and have both Infrastructure projects depend/reference it. You should not have your Core project reference it, as this would create a dependency chain to NServiceBus from your Core, which you want to avoid. If this seems odd, read up on Onion Architecture and Dependency Inversion Principle to see how this is done.