处理需要来自另一个有界上下文的数据的用例的良好做法 [英] 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.
我选择出现这三个有界上下文 (DDD):
I chose to emerge those three bounded contexts (DDD):
- IdentityAndAccessContext，主要处理用户身份验证/授权.
- SocialContext，处理会员和关于他们的所有社交信息；他们的兴趣等，类似于经典的社交网络.
- MeetingsContext，处理一些成员之间的会议.我们谈论的是作为创建者/参与者/参与者等的翻译值对象.
- 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.
基本上，在 MeetingsContext 中，会议的创建用例需要一个成员列表(为了邀请其中的一些人)，基本上是通过一个 Web 表单，用户可以在其中选择一些展示一些有趣但有趣的成员的成员轻社交信息.
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.
如您所见，SocialContext 显然是社交方式中成员数据的掌握者.
As you may figure out, SocialContext is clearly the master of members data in a social way.
我是否应该在 SocialContext 中创建一种开放主机服务，返回用例的一些相关成员数据?
Should I create a kind of Open Host Service in the SocialContext returning some relevant members data for the use case?
它会被 MeetingsContext 直接使用(REST 协议)，如果需要，可能通过反腐败层使用.
It would be consumed by MeetingsContext directly (REST protocol), maybe through an Anti-Corruption Layer if needed.
或者我应该在MeetingsContext中缓存甚至复制相关成员的数据以改进它的独立方面?
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?
推荐答案
在这些情况下，复合 UI 是一个不错的选择.您的会议上下文只需要知道成员 ID 和一些有关他们的通信偏好的信息即可建立会议.
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.
组成参与者列表不需要会议上下文的参与.此 UI 元素很可能来自社交上下文 UI，然后在选择完成后将参与者 ID 列表发送到会议上下文.
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.
以下是一些参考资料:
这篇关于处理需要来自另一个有界上下文的数据的用例的良好做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
