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?

fwiw, IdentityAndAccessContext isn't a bounded context or domain concept at all. Identity and access (authorization, authentication, acl etc.) are application concerns, not domain concerns are to be handled at application level, not on domain level — Tseng
@Tseng Check out the book "Implementing Domain-Driven Design" by Vaughn Vernon. You will see that IdentityAndAccessContext is a bounded context he takes along. — Mik378
Authentication (=Identity) is almost never a part of a domain and hence not business logic (unless your domain is some kind of security company, which manages security access for other companies, i.e. creating and issuing physical tokens to some companies employees). Authentication/Identity usually don't play a role in a business process and it's good this way, as authentication and identity may change with your infrastructure. It's like the NSA. Your identity is only checked at the gates (application). Once you're inside (domain), you're free to walk around with your name plate (user id) — Tseng
In this context, you need identification only to confirm that "logged in user is the user from the SocialContext with the id xyz" and this is clearly a responsibility of the application, not the domain — Tseng
You are mixing person with identity/accounts here. In your SocialContext Person or Emplyoee are the domain entities/aggregates. You can't "Block an emplyoee", this is nowhere a part of a business process. You can just assign (to a group/tenant/company/etc)/remove/delete it. Identity is something completely different. Identity (in simplest case) may only consists of a username, a login and an associated id (i.e. person id), so you can tell: "S/he has confirmed that s/he is this person". Nothing more, no business logic involved, its all application concern. — Tseng

Alexey Zimarev Alexey Zimarev · Accepted Answer · 2017-09-04T14:14:00

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:

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

2 Answers