Trigger and listener functions
Author's general definition under Functions section:
- listener function consumes domain events
- trigger function that produces domain events
From Param's deduction, Author uses the following when:
- trigger - any time a non-domain event is convereted to a domain event.
- listener - any time a domain event is consumed from kinesis that came from an event hub
Listener - in BFF
A *listener function consumes domain events from the event hub and cahes entities in materialized views that support queries. The synchrnous API provides command and query** operations that support the specific user interface.
The listener function plays the crucial role in an autonomous service of implementing the CQRS pattern. It is a stream processor that consumes domain events from event-hub and materializes entities in the datastore for consumption by end users. BFF services store data in a format that is most suitable for consumption by the frontend, so it is the job of the listener function to transform the entities into the desired format.
This is a single function with the single purpose of materializing entities, but there are many different domain event types to process. The function leverages the pipeline feature of the stream processing framework to preserve the maintainability of the logic for the individual event types.
Listener functions are optional. If a BFF service does not need to react to domain events, then it does not need a listener function. However, most BFF services will have a listener function. It is only the BFF services at the very beginning of the data life cycle that may not need a listener function.
Listener - in Control services
A listener function consumes lower-order events from the event hub and correlates and collates them in a micro event store.
Listener - in ESG
- Egress: The listener function consumes from the stream and filters for the event types of interest, such as all events for thing domain entity. It then transforms the data to create the external request format and invokes which ever action (send to queue, REST API, etc...)
Trigger - in ESG
Ingress: The trigger function consumes messages from queues, webhooks, topics, etcc and transforms external format to an internal event format. Then, the internal format is publised to the event hub, so that core services can react to the event.
Ingress Webhook: He calls the function a callback where the function transforms the external format to the internal event format and forwards the domain event to the event hub, so core services can react to the event.
Trigger - in BFF
A trigger function reacts to the mutations caused by commands and produces domain events to the event hub.
The trigger function fills the fundamental role in an autonomous service of implementing the database-first variation of the event sourcing pattern. It is a stream processor that consumes change events from the datastore's Change Data Capture (CDC) stream and publishes domain events to the event-hub for consumption by downstream services.
This is a single function with the single purpose of publishing domain events after a user executes a command, but there are many different change event types to process. The function leverages the pipeline feature of the stream processing framework to preserve maintainability of the logic for the individual event types.
Trigger functions are also optional, and read-only BFFs don't need one (which are BFFs at the end of the data life cycle). The datastore much support CDC streams or else we will need to use stream-first variant of the event sourcing pattern to produce domain events.
Trigger - in Control services
A trigger function applies rules to the correlated events and publishes higher-order events back to the event hub.