MSA Data Mgmt patterns -> Domain event

Domain event

Context
A service often needs to publish events when it updates its data. These events might be needed, for example, to update a CQRS view. Alternatively, the service might participate in an choreography-based saga, which uses events for coordination.

Problem
How does a service publish an event when it updates its data?

Solution
Organize the business logic of a service as a collection of DDD aggregates that emit domain events when they created or updated. The service publishes these domain events so that they can be consumed by other services.

Related patterns

·         The Saga and CQRS patterns create the need for this pattern

·         The Aggregate pattern is used to structure the business logic

·         The Transactional outbox pattern is used to publish events as part of a database transaction

·         Event sourcing is sometimes used to publish domain events

MSA Data mgmt patterns -> Command Query Responsibility Segregation (CQRS)

Problem

Once we implement database-per-service, there is a requirement to query, which requires joint data from multiple services — it's not possible. Then, how do we implement queries in microservice architecture?

 Solution

 CQRS suggests splitting the application into two parts — the command side and the query side.

• The command side handles the Create, Update, and Delete requests.
• The query side handles the query part by using the materialized views.

The event sourcing pattern is generally used along with it to create events for any data change. Materialized views are kept updated by subscribing to the stream of events.

MSA Data mgmt patterns - API Composition

API Composition

You have applied the Microservices architecture pattern and the Database per service pattern. As a result, it is no longer straightforward to implement queries that join data from multiple services.

This pattern is a direct solution to the problem of implementing complex queries in a microservices architecture.

In this pattern, an API Composer invokes other microservices in the required order. And after fetching the results it performs an in-memory join of the data before providing it to the consumer.

As evident, the downside to this pattern is the use of inefficient in-memory joins on potentially large datasets.

Problem

How to implement queries in a microservice architecture?

Solution

Implement a query by defining an API Composer, which invoking the services that own the data and performs an in-memory join of the results.

Example

An API Gateway often does API composition.

This pattern has the following benefits:

• It a simple way to query data in a microservice architecture

This pattern has the following drawbacks:

• Some queries would result in inefficient, in-memory joins of large datasets.