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