Domain Events and Event Sourcing go hand in hand? Not Exactly!

[@delu]

Would you make a video about how to synchronize microservices data when you add a new microservice to an already existing system?

[@CodeOpinion]

Yes, good topic.

[@essamal-mansouri2689]

It is funny to me that you picked up a level and a screwdriver to shake for the camera while you were talking :D Great video

[@CodeOpinion]

I randomly had them at my desk because I was putting up a picture/frame in the same room the day prior.

[@Mvision123]

I think this video could cause more confusion than it clears up. My understanding was that Aggregates raise 'domain events', and those are persisted in my event store when saving the aggregates, and loaded when I'd perform another operation on that aggregate. They also double as a way to notify other parts of the software in the same boundary.

[@CodeOpinion]

"they also double" is exactly the point I'm making. They don't. They have different purposes.

[@Mvision123]

So I rewatched it and I'm still confused implementation wise. What if performing an action on an aggregate raises both a domain event and an 'event representing stare change ' exactly the same data? Do you introduce two types and map between those?

[@nitrovent]

@@Mvision123 I would introduce two events. Alone for versioning purposes that should make it easier to change the implementation of the event sourcing and keep compatibility with the outside. Imagine you wrap the event sourcing part for persistence in let's say a repository that loads the aggregates. Then when thinking about domain events you wouldn't look into the implementation detail of that persistence.

[@slacquer2007]

I have always looked at it this way (to prevent confusion), a Domain event is an APPLICATION DOMAIN EVENT, IE, and event in that executables process space. All other events for DDD DOMAIN consumption are referred to as Integration events. This has helped the teams that I have been part of over the last several years in clarity. Just my 2 cents. Nice video though. Thanx.

[@antoniokovacevic627]

In your example at 4:45 you show how domain events are used for workflows. What about projections? Do you use event sourced events or domain events to build projections? What if the projection happens outside the boundary? Using your example, if I wanted to show order status on the UI, what are my options?

[@CodeOpinion]

Projections within your own boundary would use the events from the event stream. From outside your boundary, you're using integration (or domain) events. Your question is more leaning towards view/ui composition: kzbin.info/www/bejne/f33Fm36IZquLpcU

[@zeamessaoud]

Can you make a video about event sourcing and long lived entity when we can't keep streams short? Thank you!

[@CodeOpinion]

I touch on it in this video: kzbin.info/www/bejne/iYrWmnyuf5KBnNk

[@zeamessaoud]

@@CodeOpinion than you 👍

[@zxcmask1023]

So if specific event is important for both event sourcing and communication e.g ProductAddedToCart, would you use 1 or 2 events for that? And I guess mechanism of dispatching domain event vs ES event could differ

[@CodeOpinion]

Exactly.

[@thedacian123]

So each aggregate/entity has an event stream,Is not it?Thanks!

[@CodeOpinion]

Yes, each instance of an aggregate has its own event stream.

[@basilthomas790]

Domain Events and Event Sourcing do NOT go hand in hand but clearly Domain Events play a key role in all parts of event driven architecture. Event Sourcing is really a technical implementation detail mainly concerning recreating current state of an aggregate from a event log of ordered immutable events when processing an aggregate command. Event sourcing can be very complicated to implement and really should be defined by the needs of your business model first before making it a part of your general architecture. I think you would be better off explaining bounded contexts and aggregates for each bounded context and aggregate state changes via domain events before discussing advanced concepts like Event Sourcing which can come off as more confusing without a good understanding of Domain Driven Design. Excellent overall discussion though.

[@CodeOpinion]

I have a bunch of videos on these topics, specifically boundaries (bounded contexts) and different ways of designing aggregates.