Is it common practice to have a shared and dedicated assembly or library for messages in a distributed system?

Question

I'm talking a crack at some of the concepts behind distributed domain driven design and I'm building a proof of concept. I have three C# solutions that have specific responsibility within the overall system.

The solutions I have are:

• The write model (receives commands from a client and creates and sends events)
• The read model (receives events from write model, creates a database and exposes DTO services to the client, could potentially be 2 separate solutions)
• The client (calls services to get needed data and sends commands to the write model)

All three solutions use messaging (commands, events) through a service bus. (MassTransit in my case).

My main question is: Is it common practice to create an assembly with the messages and have each solution reference that assembly?

Extra credit: Is there anything I'm doing that seems weird or problematic in this POC? Any additional info I should be aware of when creating this type of a system?

Answer 1

Is it common practice to create an assembly with the messages and have each solution reference that assembly?

Yes. This is a common practice with messaging systems in general. For example, many NServiceBus samples employ this approach. Think of this assembly as representing your contract. In systems built upon different platforms this representation would come in the form of an XSD schema or some other schema definition mechanism.

Is there anything I'm doing that seems weird or problematic in this POC? Any additional info I should be aware of when creating this type of a system?

Everything seems to be well fitted to CQRS so far. To be fair, I should mention that it can be easy to get carried away with CQRS as a silver bullet and structure systems around it. It is often a wise decision to forgo CQRS all together. Keep focus on the business domain and use CQRS as an architectural style to implement your system, not to guide its model.