Message Types in Domain-Driven Design

Before we start to talk about message types, let's talk about what is a message.

A message is any intention of transmitting and/or processing information.

A message, you can produce and consume from message brokers, message queues, log streams, or in-memory. But, the way to do it is not important, but the message intention, and information.

Having that clear, let's identify what types of messages we have and how we can produce them! 🔥

Command Messages 🎯

The goal of this message type it invokes a functionality in another application. Usually, it represents an action or intention to produce some effects in our system and is started for an external agent, like a user.

The important concept it's that this message has a specific recipient. And every command generates a side effect in Aggregate/Context

Event Messages 🔊

A difference between commands and events is that events do broadcast to anyone interested.

• Domain Events

When we talk about DDD we talk about Domain/Business. So, when we triggered a command, this command generates a side effect in our System/Domain. This side effect we may call Domain Events, which represents business facts.

Relevant points:
- Into a system, this event type may sensibilize other contexts or your own context/aggregate.
- Our Aggregate may be produce 1-N business facts/events.

• Integration Events

Generally, if other external agents were interested in something of any journey, it's common for the context to produce an event and contains all the necessary information. An example of it is when our system needs to produce events in a Data Lake. The Data Lake is out of our domain and tech.

• Notification Events

Similar to Integration Events, the difference is the content. The Notification Event has just an ID, and your goal is to notify all interested that something happened. If the interested wants to get more information or trigger another process, doesn't matter.

Query Messages 🔛

When we need to recover some data from our system, we need to ask our application to recover it. We can use messages to do it. But, this is a little strange if we think about the async environment. So, for async applications, we can use the request-reply async pattern for this.

Conclusions

• Messages is technology agnostic
• It's import to identify your message intention
• Your journey may be more fluid and clear
• If you decide to use a Message Broker, Queue, or Log Stream, it's important to direct each message to your specific channel, liek:
  • Message Brokers is an excellent tool for Commands and Domain Events
  • Log Stream is an excellent tool for Integration Events
• Request-Reply Async pattern is a good idea for ascyn environment

References

• https://www.g2.com/articles/message-broker
• https://github.com/AntonioFalcaoJr/EDA.CleanArch.DDD.CQRS.EventSourcing
• https://www.enterpriseintegrationpatterns.com/
• https://codeopinion.com/do-you-want-to-use-kafka-or-do-you-need-a-queue/
• https://learn.microsoft.com/en-us/azure/architecture/patterns/async-request-reply