I am trying to learn more about DDD
and was going through the DomainEvents
. Let's say we have three microservices Service A
, Service B
and Service C
.
Service A
has an entity Foo
defined as below:
public class Foo : AggregateRoot
{
public string id {get; private set;}
public string name {get; private set;}
public string email {get; private set;}
}
and the Service B
is a service that depends upon the email
from Foo
while the Service C
depends on the name
from Foo
and the data is replicated from Service A
to Service B
and to Service C
whenever there is a change in the values of Foo
via a Bus
.
Guidelines about Domain Events that I came accross:
- Do not share excess information as part of the
DomainEvent
data. - When
consuming BoundedContext
knows aboutProducing BoundedContext
maybe share the Id otherwise share full information - Don't use
DomainClasses
to represent data in Events - Use
Primitive types
for data inEvents
Now the question that arose due to conflicting guidelines:
Does it mean that I should fire two different events when they change like
FooNameChange
andFooEmailChanged
and only use theid
along with theupdated value
as part of theEvent Payload
?
Or can I just make a single DomainEvent
called FooChanged
and take the state of the Foo
serialize it and fire the event. Then write up a handler as part of the same BoundedContext
that would take the data and drop it on the Bus
for any service subscribed to the message and the individual service decides on what actions to take based on the Id
that was attached and the event arg (the updated data).
If you need to talk across services, you should be perhaps looking for Integration Events instead of "Domain Events" From Microsoft Docs
What information you send within the integration events, it really depends. You have the following choices:
Publish the event such as
FooNameChanged
,FooEmailChanged
with onlyId
ofFoo
. In that scenario, if your consumers need further information of what has changed, they would need to make a call your service (perhaps a REST API call). A disadvantage of this approach is that if you have many subscribers to your event then all those services would call your service to get the details of the event almost at the same time.Publish the event with the full data (note that it is not same as your Domain) which a consuming service may need such as
PerviousValue
,CurrentValue
, etc. If your payload is not huge, this can be a good option. These types of events are typically called "FAT events"