0

在这里学习 DDD。

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

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

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

但是，当员工用户想要向用户添加新订阅时，问题就开始了，因为不再是购买自己订阅的成员，而是将订阅分配给成员的员工。

我在这里看到了多种解决方案，但似乎没有一个是完全正确的。

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

我在这里想念什么？

子问题：

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

4

1 回答 1

2

据我了解，您确实至少有两个有界上下文，但不是（仅？）您确定的那些：Subscriptions bounded context和Authorization bounded context.

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

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

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

请注意，应用程序服务没有实例化新Subscription 实体，这是MemberSubscriptions聚合的工作，您必须保护它的封装。您甚至可以将Subscription实体类保持为私有（受保护、包或您在 C# 中拥有的任何语言机制）。无论如何，对成员订阅的任何访问都必须从MemberSubscriptions聚合根（如addSubscription、removeSubscription等hasSubscription）完成。

于 2017-10-02T09:25:58.610 回答