MassTransit: patterns and practices with contract classes

Question

1. Common advice for microservice architecture is to avoid sharing message classes between the microservices. MassTransit heavily relies on .NET type information when sending / receiving the messages, so if you declare two similar types in two different microservices, it won't work.

It is possible to achieve this by some additional configuration?

2. A typical pattern in MassTransit is to declare message interfaces instead of POCO and then pass anonymous objects to Publish / Send methods. In this case, if I change something in my message interface (e.g., rename a property), I won't get a compile-time error.

Why is this recommended? How to deal with the fragility of anonymous objects?

Thanks!

Answer 1

The suggestion to prefer message interfaces is based on the principle "share schema, not type". An interface is a contract and contracts are ok to share. You mentioned yourself "avoid sharing message _classes". That's because classes also have behaviour and many projects suffered from message classes that included behavour, which could prevent deserialisation and introduce domain-specific concern to messages, which, in fact, are nothing more than property bags.

The documentation clearly states:

It is strongly suggested to use interfaces for message contracts, based on experience over several years with varying levels of developer experience.

and this suggestion, although strong, cannot be seen as a requirement. If all developers in your organisation clearly understand the concept of messages being property bags and only contain properties with primitive types and, at max, complex types that are property bags with primitive types - you can choose to work with classes instead of interfaces.

There's no recommendation or even a suggestion to use anonymous types. It is a possibility, but no more than that. You can perfectly use classes that implement message interfaces on the message producer side and then you won't be able to arbitrarily assign properties that don't exist in the interface.

You only share interfaces with your consumers, and since interfaces are read-only, you don't have an issue with getting deserialisation errors because some setters have some weird code that one developer thought is useful for the message type.

In our practice, we used interfaces but never used anonymous objects. We also widely use POCOs as messages, since developers got enough experience and understanding how messaging works.

The last thing about sharing is that we moved away from the practice of sharing message contracts using nuget packages. Although it looks attractive and safe, it creates some impediments in our daily work. We prefer copying message classes (or interfaces) over or use source packages. If teams follow good practices like versioning and weak schema, it doesn't create any issue. The only thing you need to take care of is keeping namespaces intact.