Signals

Ditto has a concept called Signal which combines common functionality of

• Commands,
• Command Responses,
• Error Responses,
• Events and
• Announcements.

Such common functionality is for example that all those have header fields in which they can be for example correlated to each other.

Signals are one of the core concepts of Ditto but they mostly are used internally for communication in the Ditto cluster. Nevertheless it is very helpful to have a basic understanding of what the Signal types are and in which communication pattern they occur.

Architectural style

Ditto uses Commands, Events, CQRS and EventSourcing. This page provides a quite good explanation of the basic concepts on all of those aspects:

Command

People request changes to the domain by sending commands. They are named with a verb in the imperative mood plus and may include the aggregate type, for example ConfirmOrder. Unlike an event, a command is not a statement of fact; it’s only a request, and thus may be refused. (A typical way to convey refusal is to throw an exception).

Event

An event represents something that took place in the domain. They are always named with a past-participle verb, such as OrderConfirmed. It’s not unusual but also not required for an event to name an aggregate or entity that it relates to; let the domain language be your guide.
Since an event represents something in the past, it can be considered a statement of fact and used to take decisions in other parts of the system.

Communication pattern

1. A command is sent to Ditto where it is then processed.
2. Either a success response or an error response is sent back to the issuer of the command.
3. In addition an event is both persisted into the datastore and published.
   The event describes that the change was applied to an entity (e.g. a Thing).
   Interested parties can subscribe for such events and follow the evolving entity.