我们如何在 DDD 中对不同类型用户的行为进行建模？答案

【问题标题】：how can we model the behaviors of different types of users in DDD?我们如何在 DDD 中对不同类型用户的行为进行建模？
【发布时间】：2014-10-01 17:34:19
【问题描述】：

我处于一种情况，我应该模拟（在域中）要求，其中用户可以是 帐单管理员 和 系统管理员 和员工。

所有管理员都可以做普通用户可以做的任何事情，但普通用户不能做其他角色可以做的事情。问题是我不明白如何通过继承用户实体来做到这一点，而且我读过这不是一个好主意，所以不想那样做..

员工、系统管理员和账单管理员是用户的不同角色。有什么建议吗？

更新：

更多信息：鉴于 Employees BC 和 Billing BC 和 System BC 是三个不同的限界上下文处理上述给定场景的理想方法是什么？

【问题讨论】：

你没有给出太多细节，但对我来说，这三个角色似乎实际上是在三个不同的有界上下文中（“bill”、“system”和“employee”似乎与我无关），因此您可能最好将它们完全独立地建模，即使这意味着一些代码重复。
是的，确实如此，它们确实属于不同的业务上下文，也许我的思维方式是错误的，我仍然在考虑数据方式..即用户表可以重新用于所有三个角色都拥有一个角色 id，也许我可以以同样的方式重用实体，这在域建模中可能是错误的想法..
一般建议是避免在 BC 之间“重复使用”任何形式。

【解决方案1】：

可能是您混合了有界概念，而继承可能也无济于事:)

通常会有一个身份和访问控制 BC。我们可以在这里找到User、Permission 和Role。

然后一个人可能有一个员工或人力资源 BC。这就是Employee 和Manager 等概念可能存在的地方。

因此，拆分这些概念可能会有所帮助。

当新员工注册时，HR BC 可能会使用 I & AC BC 订阅的服务总线发布EmployeeRegistered 事件为了注册一个新用户。

希望对您有所帮助。

【讨论】：

hmm，这看起来是一个非常简洁的解决方案，但是如果我有三个业务上下文，即 Bill、System 和 Employee，那么 I & AC BC 会监听这些 BC 发布的事件，这是理想的建模方式给定的情况？
拥有具有事件驱动架构的独特 BC 可能会让您的生活更轻松。建模可能很棘手，您在任何给定的 BC 中的模型可能需要不时地重新思考，但在某些时候，人们往往会找到一个良好的平衡和一些感觉舒适的东西。一路走来，这意味着消息很可能会发生变化。因此，鉴于我不是您环境中的领域专家，我的假设案例可能并不“理想”，但它肯定是一个起点:)