We have seen how using events can help us to decouple business processes from each other. By keeping associations between loosely coupled modules, we can prevent our system from becoming an interconnected ball of mud that is difficult to maintain in the long term.
However, throughout this book, we have been marking our commands with ICommand
and our events with IEvent
. This introduces a dependency on the NServiceBus.Core.dll
assembly that contains those interfaces. Isn't that a bad thing?
As it turns out, it can be. When you create your assembly of messages in this way, you compile it against a specific version of NServiceBus.Core.dll
. Then another service consumes that assembly. If you now want to update one service to a new version of NServiceBus, you have a problem. You have to update both services at once. This is not the glorious decoupled autonomous service utopia we signed up for.
Luckily, there is another way to identify our commands and events that does not rely on...