我们正在开发用于用户管理的 IT 服务和 HR 服务，但我们无法确定构建项目的最佳方式。
一位开发人员认为 IT 项目和 HR 项目应该在颠覆中分开，并且我们应该在每个 Messages 项目中使用 SVN 外部？
另一位开发人员认为我们应该将它们放在同一个颠覆项目中，但通过 all.sln、hr.sln 和 it.sln 将它们按文件夹划分来划分服务。
划分这些服务边界的最佳方法是什么？
【问题讨论】：
标签： nservicebus
我对 Subversion 不太熟悉，但通常我们所做的是在构建后检查到源代码控制中的服务之间的依赖关系，然后在之后分支到各自的服务中。这样做的原因是允许每个服务独立决定何时采用更新版本的共享依赖项。通过使用分支操作，您可以获得完整的依赖历史记录，并且可以随时回滚。这也使您能够使用相同依赖项的不同版本发布您的服务。在服务的后续分支中，您可以拥有不同版本的依赖项。
在这种情况下，您将签入消息程序集并将它们分支（或合并）到每个服务中。从那里您可以根据需要获取新版本。
【讨论】：
这听起来像是一个经典的循环依赖问题。了解 IT 服务是否依赖 HR 服务，或者相反，或者两者之间是否需要双向通信，对我们来说很重要。如果一个依赖于另一个，那么我的建议是有两种解决方案。假设 IT 依赖于 HR。然后在 HR 中，您可能有一个定义域对象和接口的核心项目，包括需要表示为消息的事件或命令。 Core 没有依赖项——它不引用 NServiceBus 或解决方案中的任何其他项目。在同一个解决方案中，您可能有一个引用 Core 的 HR.Infrastructure 项目。在此，您可以定义您的消息，以便它们继承自 Core 的事件和命令，以及实现 NServiceBus.IMessage（并因此引用 NServiceBus）。现在 IT 可以简单地引用 HR.Core 和 HR.Infrastructure 来处理消息。
如果需要双向通信，那么您只需将消息提取到他们自己的解决方案/项目中，并让两个基础设施项目都依赖/引用它。你不应该让你的 Core 项目引用它，因为这会创建一个从你的 Core 到 NServiceBus 的依赖链，这是你想要避免的。如果这看起来很奇怪，请阅读 Onion Architecture 和 Dependency Inversion Principle 以了解这是如何完成的。
【讨论】：