私たちは、ユーザー管理の目的でITサービスと人事サービスを開発中ですが、プロジェクトを構築する最善の方法を決めることは困難です。nservicebusソリューションを構築する最善の方法は何ですか？
ITプロジェクトと人事プロジェクトはSubversionで分離する必要があり、各MessagesプロジェクトにSVN外部を使用する必要があるとDevは考えていますか？
別の開発者は、それらを同じSubversionプロジェクトに配置するだけでなく、all.sln、hr.sln、およびit.slnをフォルダで分割することによってサービスを分割する必要があると考えています。
これらのサービス境界を分割する最も良い方法は何ですか？
私はSubversionについてあまりよく知られていませんが、私たちがやったことはサービス間の依存関係がソース管理のポストビルドにチェックインされ、その後それぞれのサービスに分岐したことです。これが行われる理由は、各サービスが、新しいバージョンの共有依存関係をいつ取り出すかを独立して決定できるようにするためです。分岐操作を使用すると、依存関係の完全な履歴が得られ、いつでもロールバックできます。これにより、同じ依存関係の異なるバージョンでサービスを出荷することもできます。その後のサービスのブランチでは、さまざまなバージョンの依存関係を持つことができます。
この場合、メッセージアセンブリをチェックインし、それらを各サービスに分岐（またはマージ）します。そこから、必要に応じて新しいバージョンを取得できます。
これは古典的な循環依存性の問題のようです。 ITサービスがHRサービスに依存しているのか、その逆であるのか、両者の間に双方向通信が必要なのかを知ることは重要です。 1つが他に依存する場合、私の推奨は2つの解決策を持つことです。 ITがHRに依存しているとします。その後、人事部では、メッセージとして表現する必要があるイベントやコマンドなど、ドメインオブジェクトとインタフェースを定義するコアプロジェクトを作成することができます。 Coreは依存関係がありません.NServiceBusやソリューション内の他のプロジェクトは参照されません。同じソリューション内に、コアを参照するHR.Infrastructureプロジェクトがある可能性があります。この中で、コアのイベントとコマンドを継承し、NServiceBus.IMessage（したがってNServiceBusを参照する）を実装するように、メッセージを定義することができます。 IT担当者は、メッセージを処理するためにHR.CoreとHR.Infrastructureを参照するだけで済みます。
双方向通信が必要な場合は、メッセージを独自のソリューション/プロジェクトにプルするだけで、両方のインフラストラクチャプロジェクトに依存/参照する必要があります。コアプロジェクトから参照する必要はありません。これにより、コアからNServiceBusへの依存関係を避けることができます。これが奇妙に思える場合は、Onion ArchitectureとDependency Inversion Principleを読んで、これがどのように行われているかをご覧ください。