CODEWITHSUNDEEP
restarchitecturedomain-driven-designbounded-contexts
Mik378
Mik378

Reputation: 22181

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

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):

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?

Upvotes: 1

Views: 551

Answers (2)

Alexey Zimarev
Alexey Zimarev

Reputation: 19630

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:

Upvotes: 1

Constantin Galbenu
Constantin Galbenu

Reputation: 17683

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.

Upvotes: 1

Related Questions