How it works...

In this recipe, we implement a command function that would be part of a Backend For Frontend service. Following the Event Sourcing pattern, we make this command atomic by only writing to a single resource. In many scenarios, such as the authoring of data, we need to write data and make sure it's immediately available for reading. In these cases, the database-first variant is most appropriate. The command just needs to execute quickly and leave as little to chance as possible. We write the domain object to the highly available, fully-managed cloud-native database and trust that the database's change data capture mechanism will handle the next step.

In this recipe, the database is DynamoDB and the change data capture mechanism is DynamoDB Streams. The trigger function is a stream processor that is consuming events from the specified DynamoDB stream. We enable the stream by adding the StreamSpecification to the definition of the table.

The stream processor logic wraps the domain object in the standard event format, as discussed in the Creating an event stream and publishing an event recipe in Chapter 1, Getting Started with Cloud-Native. The record.eventID generated by DynamoDB is reused as the domain event ID, the database trigger's record.eventName is translated into the domain event type, the domain object ID is used as partitionKey, and useful tags are adorned. The old and new values of the domain object are included in the event so that downstream services can calculate a delta however they see fit.

Finally, the event is written to the stream specified by the STREAM_NAME environment variable. Note that the trigger function is similar to the event-first variant. It just needs to execute quickly and leave as little to chance as possible. We write the event to a single resource, the highly available, fully-managed cloud-native event stream, and trust that the downstream services will eventually consume the event.