What is the best way to structure an nservicebus solution?

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?

---

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.

---

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.