我的软件是一种社交网络，会员可以在其中安排一些会议。
我选择了出现这三个有界的背景（DDD）：
基本上，在 MeetingsContext 中，会议的创建用例需要一个成员列表（以便邀请其中一些成员），基本上是通过用户选择某些成员的Web表单提出一些有趣但轻松的社交信息。
正如您所知， SocialContext 显然是社交方式的成员数据的主人。
我应该在 SocialContext 中创建一种开放主机服务，为用例返回一些相关成员数据吗？
直接使用 MeetingsContext （REST协议），如果需要，可以通过反腐败层使用。
或者我是否应该在 MeetingsContext 中缓存甚至复制相关成员的数据，以改善其自包含方面？
使用缓存解决方案，缓存将以最终一致性方式同步。
在这种情况下，什么是好的做法？
答案 0 :(得分：1)
这取决于但我会使用反腐败层（ACL）来分隔三个有界上下文。
关于缓存的使用：你可以使用它;这与ACL正交。 ACL可以通过缓存进行修饰以加快速度，或者它本身可以是保留远程数据的本地副本的本地持久性。
关于最终的一致性：当然，您将在有界上下文之间保持最终的一致性，您的设计必须考虑到这一点。
基本上，在MeetingsContext中，会议的创建用例需要一个成员列表（以便邀请其中一些成员），基本上是通过Web表单，用户选择一些成员呈现一些有趣但轻松的社交信息。
UI可以是一个特殊情况，它结合了更有界的上下文中的数据;不要让UI模糊有界上下文之间的清晰分离。
答案 1 :(得分：1)
在这些情况下，复合UI是一个不错的选择。您的会议环境不需要了解会员ID以及有关其通信偏好的一些信息，以便建立会议。
撰写参与者列表不需要会议上下文参与。这个UI元素很可能来自社交上下文UI，然后在选择完成时将参与者ID列表发送到会议上下文。
一般规则是为了避免在屏幕上显示某些内容而在上下文之间传输数据。负责任的背景应该是这样做的。
以下是一些参考资料：