Good practice to handle a use case requiring data from another bounded context

Question

My software is a kind of social network where members can, among other features, schedule some meetings between them.

I chose to emerge those three bounded contexts (DDD):

• IdentityAndAccessContext, basically dealing with user authentication/authorisation.
• SocialContext, dealing with Members and all social information about them; their interests etc., akin a classical social network.
• MeetingsContext, dealing with meetings between some members. We're talking about translated Value Objects as Creators/Attendees/Participants etc.

Basically, in the MeetingsContext, the meeting's creation use case demands a list of members (in order to invite some of them), basically through a Web form where user selects some members presenting some interesting but light social information.

As you may figure out, SocialContext is clearly the master of members data in a social way.

Should I create a kind of Open Host Service in the SocialContext returning some relevant members data for the use case?

It would be consumed by MeetingsContext directly (REST protocol), maybe through an Anti-Corruption Layer if needed.

Or should I rather cache or even maybe duplicate relevant member's data in the MeetingsContext to improve it's self-contained aspect?

With the caching solution, the cache would be sync in an eventual consistency manner.

What is a good practice in this case?

Answer 1

Composite UI is a good choice in these situations. Your meeting contexts does not need to know anything more than member id and perhaps some information about their communication preferences in order to establish a meeting.

Composing a list of participants does not require the meeting context involvement. This UI element can very well come from the social context UI and then send the list of participant ids to the meeting context, when selection is complete.

The general rule is to avoid data transmission between contexts just in sake of showing some stuff on the screen. The responsible context should be doing that.

Here are some references:

• The secret of better UI composition by Mauro Servienti
• Composite UIs for Microservices - A Primer by Jimmy Bogard

Answer 2

It depends but I would use an Anti Corruption Layer (ACL) in order to separate the three Bounded Contexts.

Regarding the use of a cache: you could use that; this is orthogonal to ACL. The ACL could be decorated by a cache to speed things up or it could itself be a local persistence that keeps a local copy of the remote data.

Regarding eventual consistency: of course you will have eventual consistency between bounded contexts, your design must take that into consideration.

Basically, in the MeetingsContext, the meeting's creation use case demands a list of members (in order to invite some of them), basically through a Web form where user selects some members presenting some interesting but light social information.

The UI could be a special case that combines data from more bounded contexts; don't let the UI blur the clear separation between bounded contexts.