Great Read !. Domain events != CDC. I have seen teams lean more towards CDC because it is easy to plug in like put Debezium but they forget it captures changes, not intent.
Loved the line: "Domain Events are not emitted because of DB changes; they are emitted before or during them, reflecting domain decisions." That’s a mindset shift
A good integration event example could be UserUpdated(userId=12345).
A good CRM system could utilize even 100 user events, even just phone number could be affected by PhoneNumberAdded, userMovedToNewCountry, PhoneNumberVerificationExpired, CustomerUpdatedContacts, etc. But exposing them to external systems would be a leaky abstraction as almost nobody outside SRM cares about such details.
Imagine estimating for any larger refactoring with 20 services might-be listening to 100 events.
This event is also better than CDC as it does not couple database structures. A service like accounting could just call some GET crm-service.internal/users/123 and map required properties to its own data model.
Though this pattern is terrible for flows like orders where action intent is critical detail.
A good integration event example could be UserUpdated(userId=12345).
A good CRM system could utilize even 100 user events, even just phone number could be affected by PhoneNumberAdded, userMovedToNewCountry, PhoneNumberVerificationExpired, CustomerUpdatedContacts, etc. But exposing them to external systems would be a leaky abstraction as almost nobody outside SRM cares about such details.
Imagine estimating for any larger refactoring with 20 services might-be listening to 100 events.
This event is also better than CDC as it does not couple database structures. A service like accounting could just call some GET crm-service.internal/users/123 and map required properties to its own data model.
Though this pattern is terrible for flows like orders where action intent is critical detail.
As someone who quickly forgets concepts, I still look up different patterns. This looks like a nice article comparing the CDC & Domain Events.
Thanks, Marcos & Raul!
Thanks, brother!
That means a lot coming from you Neo!
Thanks!
Great explanation of often-confused concepts. Thanks, Marcos and Raul.
Also, thanks for the mention!
Thanks, Saurabh!
Great Read !. Domain events != CDC. I have seen teams lean more towards CDC because it is easy to plug in like put Debezium but they forget it captures changes, not intent.
Loved the line: "Domain Events are not emitted because of DB changes; they are emitted before or during them, reflecting domain decisions." That’s a mindset shift
Thanks a ton Marcos and Raul !
Glad you like !
I've seen the same: teams are not used to implement domain events and systems are not meant to work like that, so they implement Change Data Capture.
Appreciate it! And yes, that mindset shift is everything.
It’s tempting to plug in Debezium and call it a day, but if teams never model intent, they miss the whole point of EDA.
Domain Events aren’t a side effect; they are the design.
Thanks!
It miss 3rd option - integration events.
A good integration event example could be UserUpdated(userId=12345).
A good CRM system could utilize even 100 user events, even just phone number could be affected by PhoneNumberAdded, userMovedToNewCountry, PhoneNumberVerificationExpired, CustomerUpdatedContacts, etc. But exposing them to external systems would be a leaky abstraction as almost nobody outside SRM cares about such details.
Imagine estimating for any larger refactoring with 20 services might-be listening to 100 events.
This event is also better than CDC as it does not couple database structures. A service like accounting could just call some GET crm-service.internal/users/123 and map required properties to its own data model.
Though this pattern is terrible for flows like orders where action intent is critical detail.
It miss 3rd option - integration events.
A good integration event example could be UserUpdated(userId=12345).
A good CRM system could utilize even 100 user events, even just phone number could be affected by PhoneNumberAdded, userMovedToNewCountry, PhoneNumberVerificationExpired, CustomerUpdatedContacts, etc. But exposing them to external systems would be a leaky abstraction as almost nobody outside SRM cares about such details.
Imagine estimating for any larger refactoring with 20 services might-be listening to 100 events.
This event is also better than CDC as it does not couple database structures. A service like accounting could just call some GET crm-service.internal/users/123 and map required properties to its own data model.
Though this pattern is terrible for flows like orders where action intent is critical detail.