Good practice to handle a use case where data is mastered by another Bounded Context

[Michael Azerhad]

Hi,

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:

• IdentityAndAccessContext  (basically dealing with user authentication/authorisation)
• SocialContext (dealing with Members and all information data about them; their interests etc...akin a classical social network)
• MeetingsContext (dealing with schedule of 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.

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 autonomy aspect? 

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

What is a good practice in this case?

Thanks :) 

 

[Samuel Francisco]

I think the MeetingsContext should have the list of members as a Read Model, reacting to the events from the others Bounded Contexts, improving his autonomy and decrising the coupling between the systems.

[andho]

I agree with Samuel, but here is an alternative.

As users are compiling a list of members (from a read model derived from SocialContext), I would choose to trust the data submitted to the MeetingsContext. In this case, the User information (maybe just the ID) becomes a ValueObject in the MeetingsContext.
Now, the case where a Client intentionally sends malicious/invalid data. During projections you will find out that the user ID actually does not exist, and you can take corrective action.

If you don't want to trust the Client (user), then you could even reverify the data in the Application layer (but this would lead to duplicate logic if many different interfaces are provided, ie. WebForm, API).

[@yreynhout]

As an alternative, you can use a MAC ;-)