as " star ", don't miss a good article!
1 defines
to model the activities that occur in the field as a series of discrete events. Each event is represented by a domain object. The
domain event is an integral part of the domain model and represents what happens in the domain.
A domain event will lead to further business operations. While decoupling the business, it also helps to form a complete business closed loop. A
domain event can be a step of a business process, such as a follow-up action triggered after an event occurs, such as a password being entered incorrectly three times in a row, triggering the action of locking the account.
2 Words to identify field events
"If..., then..."
"When you are done..., please notify..." (The notice here does not constitute an event by itself, but only indicates that we need to send to the outside world Notice.)
"When... happens, then..." etc.
"If something like this happens, it is not important; if something like that happens, it is important"
In these scenes, if something happens After the event, further operations will be triggered, so this event is likely to be a domain event. Because domain events need to be published to external systems, such as to another bounded context. Since such an event is handled by the subscriber, it will have a profound impact on the local and remote contexts. Why should
use eventual consistency for events in the field, instead of direct invocation of traditional SOA? A principle of
aggregation: at most one aggregation instance can be changed in a transaction. Therefore, other aggregate instances in the local bounded context of
can synchronize
by means of domain events to keep the remote dependent system consistent with the local system. Decoupling the local system and the remote system also helps improve the scalability of the collaboration services between the two parties.
aggregates to create and publish events. The subscriber can store the event first, and then forward it to the remote subscriber, or forward it directly without storing it. Unless MQ shares the data storage of the model, XA is required for instant forwarding.
considers that during the off-peak period of the system, the batch process usually performs some system maintenance work, such as deleting expired objects, creating new objects to support new business needs or notifying users of important events. Such batch processing usually requires complex queries and huge transaction support. What if there is redundancy in these batch processes? We capture everything that happens in the
system in the form of events, and then publish the events to the subscribers for processing. Can the system be simplified?
for sure! It can eliminate complex queries in the previous batch process, because we can know exactly when and what happened, and the bounding context also knows what to do next. When a domain event is received, the system can process it immediately. The original batch centralized processing process can be dispersed into many smaller-grained processing units, business requirements can be met more quickly, and users can proceed to the next step in time.
Domain event-driven design can cut off the strong dependencies between domain models. After the event is published, the publisher does not need to care about the success of subsequent subscriber event processing. This can realize the decoupling of the domain model and maintain the independence and data of the domain model. Consistency. When the domain model is mapped to the microservice system architecture, domain events can decouple the microservices. The data between microservices does not require strong consistency, but is based on eventual consistency. Some domain events of
occur between aggregations in microservices, some occur between microservices, and there are scenarios where both are happening. Generally speaking, cross-microservice domain event processing is mostly. In the design of microservices, events in different fields are handled differently.
3 In microservices
When a domain event occurs in the aggregation room in the microservice, the event entity construction and event data persistence are completed after the domain event occurs, the publisher aggregation publishes the event to the event bus, and the subscriber receives the event data to complete subsequent business operations . The integration of most events in
microservices occurs in the same process, and the process itself can control transactions well, so it is not necessary to introduce MQ. However, if an event updates multiple aggregations at the same time, according to the principle of "only update one aggregation at a time", you can consider introducing an event bus.
Application services in microservices can complete cross-aggregation access by means of service invocation through cross-aggregated service orchestration and composition.Ask, this method is usually used in scenarios that require high real-time and data consistency. This process will use distributed transactions to ensure that the data of the publisher and the subscriber are updated successfully at the same time.
In microservices, instead of using less domain events, it is recommended to use less event bus . In DDD, data management is based on aggregation. If one operation will modify multiple aggregated data in the same microservice, the data consistency of multiple aggregations must be guaranteed. In order to decouple different aggregations, distributed transactions must be used. Or event bus. It is not convenient to use event bus to manage the relationship between services and data. Distributed transaction technology like saga can be used. In short, you need to ensure the consistency of your different aggregate business rules and data, and minimize the complexity of system construction.
4 Between microservices
Cross-microservice domain events will achieve business collaboration between different bounded contexts or domain models, mainly for decoupling, reducing the pressure of real-time service access between microservices. Events in the
domain occur frequently among microservices, and the event handling mechanism is more complicated. Cross-microservice events can promote the direct flow of business processes or data between different subdomains or microservices. The
cross-microservice event mechanism should generally consider event construction, publishing and subscription, event data persistence, MQ, and even event data persistence may need to consider the introduction of distributed transactions. The access between microservices can also be directly called by application services to achieve real-time access to data and services. The drawback is that simultaneous changes of data across microservices require the introduction of distributed transactions. Distributed transactions will affect system performance, increase the coupling between microservices, and try to avoid using them.
5 Domain event overall architecture
5.1 Event construction and release The basic attributes of
events
include at least:
event unique identifier (globally unique, events can be unambiguously transmitted in multiple bounded contexts)
occurrence time
event type
event source
That is to record the data of the event itself and the background of the event. The
business attribute
records the business data at the moment of the event, and these data will be transmitted to the subscriber along with the event to carry out the next business operation. The basic attributes of
events and business attributes together constitute the event entity, which depends on the aggregate root. After the domain event occurs, the business data in the event is no longer modified, so the business data can be saved in the form of serialized value objects. This storage format is also easier to parse and obtain in the message middleware. In order to ensure the unification of the event structure,
will also create an event base class DomainEvent, and subclasses can extend attributes and methods. Since the event does not have too many business behaviors, the implementation method is generally relatively simple. Before the
event is released, the event entity needs to be constructed and persisted. There are many ways to publish events.
can be published to the event bus or MQ
through application services or domain services. Incremental event data can also be obtained from the event table using timing programs or database log capture technology, and published to MQ
5.2 Event data persistence The meaning of
data reconciliation between systems
realizes the audit of publisher and subscriber event data
When encountering MQ, subscriber system downtime or network interruption, the follow-up business flow can be continued after the problem is solved to ensure data consistency . The
implementation scheme
is persisted to the event table of the local business DB, and local transactions are used to ensure the consistency of business and event data.
is persisted to the shared event DB. Business and event DBs are not in the same DB, and their data persistence operations will cross DBs. Therefore, distributed transactions are required to ensure strong consistency of business and event data, which has an impact on system performance.
5.3 Event Bus (EventBus)
Significance
Implementation of micro Aggregate inter-domain events within the service and provide services such as event distribution and reception.
is an in-process model that traverses the subscriber list between aggregations in microservices, and transfers data synchronously or asynchronously. If the
event distribution process
is a subscriber in the microservice (other aggregation), it will be directly distributed to the subscriber outside the specified subscriber
microservice, and the event data will be saved to the event library (table) and sent asynchronously to MQ
. Service inside and outside orderFor readers, first distribute to internal subscribers, save the event message to the event library (table), and then asynchronously send it to MQ
5.4 MQ
Cross-microservice domain events mostly use MQ to achieve cross-microservice event publishing and subscription.
Although MQ has its own persistence function, but in the middle process or after subscribing to the data, there is a problem before processing, and data reconciliation is required, so that it is impossible to find the data version at the time of publishing and after processing. The key business data recommendation is still out of the database.
5.5 Event reception and processing The
microservice subscriber adopts a monitoring mechanism at the application layer to receive event data in MQ. After the event data is persisted, further business processing can be started. Domain event processing can be implemented in domain services.
Some classmates will ask whether the event has been successfully consumed (the consumer has successfully received the message or the consumer has successfully processed it). How do you generally notify the message producer?
Because the event publisher has the original persistent data of the event entity , Event subscribers also have persistent data they receive. Generally, the consistency of the data can be checked by means of periodic reconciliation.
6 Summary
Today we mainly talked about domain events and the processing mechanism of domain events. Domain event-driven is a very mature technology, which has been widely used in many distributed architectures. Domain events are an important concept of DDD. When designing, we must focus on domain events, use domain events to drive the flow of business, try to use event-based eventual consistency, reduce the pressure of direct access between microservices, and realize microservices. Decoupling between the maintenance of domain model independence and data consistency.
In addition, the domain event-driven mechanism can implement a model of publisher and N subscribers, which is basically impossible in the traditional direct service call design.
Refer to
"Realizing Domain Driven Design"
Domain Events: The Key to Decoupling Microservices
"Domain Driven Design"
