構建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以瞭解如何完成此操作。