I’m looking at implementing something akin to a EIP Content Enricher and am wondering if a message mutator is a suitable hook to use for this?
Further to that, because only specific messages will need enrichment would it be preferable to implement a single mutator that uses a register (by message type) of enrichers or should I add a new mutator for each enrichment operation that starts by checking the message type?
OR should I just call at publish i.e. bus.Publish(enricher.Enrich(new Message()))
The short answer is: probably yes.
The long answer is:
Thanks for providing the EIP link. It mentions zipcode and state, which modifies the content of a message.
I’m usually not too happy with message mutators actually modifying the content of a message. I’ve used them before to modify or add headers on some occasions. If integrating with external parties, like brokers like BizTalk do, then this could be a necessity. With brokers like that, we have something in the middle that receives messages from things, transforms them (from XML to JSON, modifies zipcode, etc) and sends them to another thing.
With NServiceBus that’s different. There is nothing in the middle. You’d build either a mutator on the sender side, or on the receiver side. If they are already aware of the transformation, why build this into a message mutator, which is kind of hidden away? Why not make it explicit and put this inside the handler. Obviously, a call to some class, inside a handler. This assumes it’s some transformation like a zipcode. I am not aware of any specific requirements that you have.
That would mean the responsible endpoint defines a contract and doesn’t really care about what others do with its message. In the case of a command (sending a message) the receiver is the one responsible for defining the contract. In the case of an event (publishing a message) the publisher is the one responsible.
After thinking about it more since posting I was starting to prefer the idea of enrichment directly from the handler so your explanation mostly confirms that. Your definition of the responsible endpoint is useful too.