why do we need messaging system (maybe massaging...)?

Messages. messages all about messages. Is that a real thing - do we need them? Messages are nasty, you send it in one piece of code, receive in other and you can't just debug that. No function calls, no stack trace - so how you people like those messages?

Primero messages are great way to allow separate application components, especially when we are inheriting legacy solution with huge number of dependences.

To start with messaging, we don't need Kafka, MSMQ, rabbitMQ or other animals - we can start with stuff that are already in our .Net tool case. 
In below example we use a very basic approach that enables us to avoid method calls in destination with our parameters and we are using queue so we are messaging each other!

let's define a queue(s):

Then we can add a producer (something that will be adding messages, like our web api controller):

and a consumer (like our database writer):

And as you can see, our data is enriched by database query and send to next processing step.

What we need to know that the same message can be sent to multiple queues, so that means we can speedup some processes (for example those that were processed in a parallel loop).

Let's just have a look and think about this solution. We need to start listeners in a new thread and keep them alive (if they die, our queue will be bigger and bigger and bach... out of memory) - try/catch whenever posible to keep the process going. 

For now our producer don't need to know anything about consumer (and vice-versa), just the queue name and payload. That allows us to reduce some coupling in a first go (and maybe add a bit compute as well).

So next step could be to isolate a bunch of classes that could be a small service and then instead of using internal queue we could use other animals like RabbitMQ and so on :-).

Pls let me know in comments if that stuff have a value for you!

git: here

gist: here

documentation: here