Search code examples
restdomain-driven-designmessagingbounded-contexts

API vs Events in DDD across bounded contexts


When integrating across Bounded Contexts in DDD which of the following is considered better practice?

1) Publish events when an entity changes within a source BC, listen to those events in a consuming BC, shape that data into the entity required and store it within the consuming BC.

or

2) Make an API call synchronously to the BC that owns an entity when that information is required by another BC.

or is there another option that's considered better practice than the above?


Solution

  • If you are interested in autonomy, then you don't want to have services that require other services to be available.

    So you should probably be thinking the other way around -- how does the consumer work when the remote data provider is unavailable is your primary use case, and then consider whether there are any enhancements to add when the data provider is live.

    This typically means that the each service caches a copy of the data that it will need.

    Having the consumers pull data that they need is commonly simpler than trying to push the data to them -- see Greg Young's talk on Polyglot Data.