02. Domain model

A business process consists of multiple steps. In a microservices architecture, each one of these steps is usually executed in different services. Therefore, a business process step communicates with others using messages. Services implement message handlers for the messages that they need to act on to accomplish the mentioned interaction between steps.

These messages can be considered input messages when they start a business process step or response messages when they are a response to a previously made request or a notification that a step needs to receive to ensure the success of the distributed transaction. The following model illustrates these concepts.

Also, the message handlers are idempotent so that message producers can use retry policies to ensure the correct delivery of messages, supporting a more resilient system with more reliability in business processes. For that reason, all the messages are associated with a MessageSlip that contains the following information:

• Message identifier – a unique identifier of a message;
• Correlation identifier – a unique identifier of the transaction;
• Conversation identifier – the message identifier of the previous message in the transaction.

Furthermore, message handlers also provide compensation for messages that require it. Each process step state can be considered as failed after a specific time interval without being updated, which is considered a timeout.

Finally, each process step can have multiple handlers, and each handler can be assigned to multiple steps in order to achieve high reusability of business logic. Finally, a message can have multiple handlers, depending on the process step they are being applied to.