232
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
public
string
UserId {
get
; }
public
string
UserName {
get
; }
public
int
CardTypeId {
get
; }
public
string
CardNumber {
get
; }
public
string
CardSecurityNumber {
get
; }
public
string
CardHolderName {
get
; }
public
DateTime CardExpiration {
get
; }
public
Order Order {
get
; }
public
OrderStartedDomainEvent
(Order order,
string
userId,
string
userName,
int
cardTypeId,
string
cardNumber,
string
cardSecurityNumber,
string
cardHolderName,
DateTime cardExpiration)
{
Order = order;
UserId = userId;
UserName = userName;
CardTypeId = cardTypeId;
CardNumber = cardNumber;
CardSecurityNumber = cardSecurityNumber;
CardHolderName = cardHolderName;
CardExpiration = cardExpiration;
}
}
This is essentially a class that holds all the data related to the OrderStarted event.
In terms of the ubiquitous language of the domain, since an event is something that happened in the
past, the class name of the event should be represented as a past-tense verb, like
OrderStartedDomainE
vent or OrderShippedDomainEvent. That’s how the domain event is
implemented in the ordering microservice in eShopOnContainers.
As noted earlier, an important characteristic of events is that since an event is something that
happened in the past, it shouldn
’t change. Therefore, it must be an immutable class. You can see in
the previous code that the properties are read-
only. There’s no way to update the object, you can only
set values when you create it.
It’s important to highlight here that if domain events
were to be handled asynchronously, using a
queue that required serializing and deserializing the event objects, the properties would have to be
“private set” instead of read
-only, so the deserializer would be able to assign the values upon
dequeuing. This is not an issue in the Ordering microservice, as the domain event pub/sub is
implemented synchronously using MediatR.
Dostları ilə paylaş: