DDD 用户域特定设置答案

【问题标题】：DDD User-Domain specific settingsDDD 用户域特定设置
【发布时间】：2016-12-30 00:26:23
【问题描述】：

我目前正在开发负责身份验证的微服务（负责身份和权限的有界上下文）。我们有基于用户角色的特定设置，这些用户角色与另一个域相关联，但用于生成令牌

（类似https://developer.zendesk.com/rest_api/docs/core/custom_roles）

举个例子

role_can_write_booking: true,
fetch_products_type : "all/forUsersCompanyOnly"

等等

我应该将此信息保留为 Identity BC 的一部分，还是每个域都应保留它作为设置的一部分。例子： role_can_write_booking : true 在预订有界上下文中， fetch_products_type : "all/forUsersCompanyOnly" 在 Booking 产品有界上下文中。 ?

【问题讨论】：

只是好奇...你有很多跨多个限界上下文的角色吗？你能举一个这样的角色的例子吗？根据我的经验，每个子域的通用语言倾向于定义自己的角色/角色名称。
@guillaume31 每个有界上下文将呈现一种功能，例如会计、预订、产品等。其中一个例子是我们将能够拥有负责预订的代理。有些人可能可以访问预订和产品等。在全球范围内，他们都是代理，但在通用语言中，一个是 BookingAgent，一个是 ProductAgent。其中一些将能够只读，其中一些将能够编辑等
无法给出比例如更精确的角色名称。 [预订+负责产品] 对我来说就像是一种气味。如果角色真的是 per-BC 怎么办？再说一次，我不在你的域中。
@guillaume31 我们的想法是为我们的客户提供灵活性。我的公司可能有员工负责预订和产品管理。他将是 Booking BC 中的 BookingAgent，产品 BC 中的 ProductManager，但话又说回来，另一个客户可能会决定我们系统中他公司的 ProductManager 将能够创建产品，但不能删除它们，这代表了不同的权限集.
我没有质疑自定义角色的必要性。问题是，在您刚刚给出的两个示例中，我只能看到 Product 权限，而不是 Booking 权限，这可能表明您的角色是每个 BC，而不是跨 BC（因此我最初的问题）。在有界上下文的范围内严格定义和存储您的角色可能会很好地解决大部分问题，因为用户不会想创建胖的、包罗万象的角色。

标签： domain-driven-design microservices

【解决方案1】：

这取决于。无论哪种方式都需要权衡取舍。如果您将所有信息存储在身份上下文中，则它需要了解所有其他上下文，并且每当某些权限或访问规则在任何上下文中发生更改时都需要更改。如果每个上下文管理自己的权限规则，那么他们只需要了解自己。

您还需要考虑如何管理事物。是否有集中管理角色和权限的概念？

这还取决于角色需要的课程或细粒度以及域在身份/角色/权限等方面的复杂程度。

如果您有非常粗略的角色（即“管理员”、“用户”），那么我可能会按照让身份上下文管理用户帐户和角色的方式做一些事情，但将权限方面留给每个单独的上下文。即“这是一个具有角色 X 和 Y 的经过身份验证的用户”，然后每个单独的上下文确定这允许什么。

【讨论】：