Why are MassTransit highly recommended interfaces for messaging contracts?

Question

MassTransit states that we should use interfaces for messaging contracts:

It is highly recommended that you use interfaces for messaging contracts based on several years of experience with varying levels of developer experience. MassTransit will create a dynamic message implementation interface, providing a clean separation of the message from the consumer.

Source: MassTransit Usage Documents Creating a Post Contract

What is the disadvantage of using DOC POCO instead of interfaces, what are the obvious advantages of interfaces over classes in the context of messaging with MassTransit?

On the other hand, NServiceBus is great for POCO and, of course, it makes sense not to use internal classes such as a domain object, see below.

Source: NServiceBus Messages Messages, Events, and Commands

When creating messages, you should follow these guidelines:

• Messages must be simple POCO objects.
• Messages should be as small as possible.
• Messages must comply with the principle of single responsibility.
• Classes used for other purposes (for example, domain objects, data access objects, and UI binding objects) should not be used as messages.

Answer 1

Although this is not directly related to MassTransit, I would say that the reason is encapsulation. By creating a simple POCO with setters, but passing it behind an interface, promises only getters that encapsulate data in the DTO.

public class Program { static void Main(string[] args) { User user = new User() { Username = "user99" }; Account account = new Account(user); } } public interface IUser { string Username { get; } } public class User : IUser { public string Username { get; set; } } public class Account { private IUser user; //Currently used in main public Account(User user) { user.Username = ""; //This is allowed this.user = user; } //But consider this ctor public Account(IUser user) { //user.Username = ""; //Not allowed this.user = user; } ... }