10 Comments
User's avatar
Neo Kim's avatar

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!

Expand full comment
Raul Junco's avatar

Thanks, brother!

Expand full comment
Marcos F. Lobo 🗻's avatar

That means a lot coming from you Neo!

Thanks!

Expand full comment
Saurabh Dashora's avatar

Great explanation of often-confused concepts. Thanks, Marcos and Raul.

Also, thanks for the mention!

Expand full comment
Raul Junco's avatar

Thanks, Saurabh!

Expand full comment
Shrinjit Dash's avatar

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 !

Expand full comment
Marcos F. Lobo 🗻's avatar

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.

Expand full comment
Raul Junco's avatar

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!

Expand full comment
LUKAS's avatar

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.

Expand full comment
LUKAS's avatar

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.

Expand full comment