1

我的软件是一种社交网络，除其他功能外，成员还可以在其中安排他们之间的一些会议。

我选择出现这三个有界上下文（DDD）：

  • IdentityAndAccessContext，主要处理用户身份验证/授权。
  • SocialContext，处理会员和有关他们的所有社交信息；他们的兴趣等，类似于经典的社交网络。
  • MeetingsContext，处理一些成员之间的会议。我们正在谈论作为创作者/参与者/参与者等的翻译价值对象。

基本上，在MeetingsContext中，会议的创建用例需要一个成员列表（以便邀请其中一些成员），基本上是通过一个 Web 表单，用户在该表单中选择一些提供一些有趣但轻松的社交信息的成员。

您可能会发现，SocialContext显然是以社交方式掌握成员数据。

我应该在SocialContext中创建一种开放主机服务，为用例返回一些相关的成员数据吗？

它将由MeetingsContext直接使用（REST 协议），如果需要，可能通过反腐败层。

或者我应该缓存甚至可能在MeetingsContext中复制相关成员的数据以改进它的自包含方面？

使用缓存解决方案，缓存将以最终一致性的方式同步。

在这种情况下有什么好的做法？

4

2 回答 2

1

这取决于但我会使用反腐败层 (ACL) 来分离三个有界上下文。

关于缓存的使用：你可以使用它；这与 ACL 正交。ACL 可以由缓存修饰以加快处理速度，或者它本身可以是本地持久性，保留远程数据的本地副本。

关于最终一致性：当然，您将在有界上下文之间获得最终一致性，您的设计必须考虑到这一点。

基本上，在 MeetingsContext 中，会议的创建用例需要一个成员列表（以便邀请其中一些人），基本上是通过一个 Web 表单，在该表单中，用户选择一些提供一些有趣但轻松的社交信息的成员。

UI 可能是一种特殊情况，它结合了来自更多有界上下文的数据；不要让 UI 模糊有界上下文之间的清晰分隔。

于 2017-09-04T10:32:11.040 回答
1

在这些情况下，复合 UI 是一个不错的选择。您的会议环境除了成员 ID 以及一些关于他们的通信偏好的信息之外，不需要知道任何其他信息即可建立会议。

组成参与者列表不需要会议上下文参与。此 UI 元素很可能来自社交上下文 UI，然后在选择完成后将参与者 ID 列表发送到会议上下文。

一般规则是避免上下文之间的数据传输，只是为了在屏幕上显示一些内容。负责任的环境应该这样做。

以下是一些参考资料：

于 2017-09-04T14:14:00.113 回答