如何模拟这个领域驱动的设计挑战？

Question

在这里学习DDD。

有两种用户会员和员工。会员可以拥有订阅列表，并且可以随时购买其他订阅。员工用户还可以向成员添加订阅。当员工用户向成员系统添加订阅时，应记住谁添加了此订阅。

会员和员工用户处于完全不同的有限环境中。他们拥有不同的权利和他们可以参加的不同群体。因此，我创建了一个成员聚合根，其中包含单独的有界上下文“成员”中的订阅列表。然后我在seprate Bounded context Staff中创建了Staff聚合根。

当成员想要购买额外订阅时，会员很容易，因为订阅是成员聚合和成员有界上下文的一部分，因此会将新订阅附加到成员。

但是，当员工用户想要向用户添加新订阅时，问题就开始了，因为不再是购买订阅服务的会员，而是指定会员订阅的员工。

我在这里看到了多个解决方案，但它们似乎都没有完全正确。

1. 将Subscription实体添加到Staff聚合。 （尴尬，因为员工没有订阅）
2. 当员工用户添加订阅时，引发一个事件，通过成员聚合将成员订阅添加到成员。 （尴尬，因为它不是添加订阅的成员）
3. 直接从员工服务呼叫成员聚合（违反DDD原则）。
4. 在自己的有界上下文中移动订阅，并使其成为聚合根。 （会错，因为会员与他/她的订阅关系密切）

我在这里缺少什么？

子问题：

是否允许跨多个有界上下文服务使用相同的DTO？

Answer 1

根据我的理解，你确实至少有两个有界的背景，但不是（只有？）你确定的那些：Subscriptions bounded context和Authorization bounded context。

Subscriptions bounded context包含成员获取新订阅或取消现有订阅时使用的逻辑。规则是这样的：成员可以拥有他想要的订阅数量。其他人可以添加订阅。

Authorization bounded context包含user可以向成员添加订阅的规则。如果用户是会员，那么他可以仅将订阅添加到他的会员帐户。如果用户来自员工，那么他可以将订阅添加到其他成员但不是自己的成员，除非他也是成员（第一条规则）。

有两个有界的上下文，你需要集成它们。在用例＆＃34;添加订阅成员＆＃34;有两个有界的上下文。您可以在应用程序服务中通过首先调用Authorization bounded context中的查询/域服务来检查当前经过身份验证的用户是否可以向该成员添加订阅。如果他可能不会返回异常，否则加载MemberSubscriptions聚合，请调用addSubscription(subscriptionId, idIfTheUserThatAddsTheSubscription, subscriptionType, etc...)然后将聚合内容保存在存储库中。

请注意，Application服务没有实例化新的Subscription实体，这是MemberSubscriptions聚合的工作，您必须保护其封装。您甚至可以将Subscription实体类保持为私有（受保护，包或您在C＃中拥有的任何语言机制）。无论如何，必须<{1}}聚合根（例如MemberSubscriptions，addSubscription，removeSubscription等）对成员订阅的任何访问权限。< / p>