Domain driven design 决定何时需要显式建模域角色的准则

我正在寻找一些关于何时必须在域模型中显式建模角色的指导原则

我将用一个例子来解释我目前的立场

假设我们正在建立一个医疗保健系统，业务需求表明

“只有具备3年以上经验和一定经验的医生 “有资格做手术”

在这种情况下，很明显，做手术的动作只能由扮演医生角色的人来执行，医生需要满足某些先决条件才能执行该动作

docter.performSurgery() 

所以基本上所有的医生都不一样

此方法可能会检查是否满足前提条件

因此，在上述情况下，我将明确地为角色建模

现在让我们考虑另一种情况。

只有管理员才能批准资金转账

在上述情况下，我不认为有必要在域中为这个角色建模，因为它们没有规则来区分我域中的一个管理员和另一个管理员

任何具有管理员权限的个人/用户登录都可以执行此操作，我宁愿将其设计到我的安全基础结构中，并确保

approveTransfer（）

仅当当前登录的用户具有管理员权限时，才会调用在应用程序层上调用的方法

所以“域模型”，我的意思是像Account类这样的类不知道这个规则，这是通过AOP或者AccountService类等在应用层编码的

---

智者对此有何看法？：）

在设计聚合时，我总是问自己一个重要的问题

• 我试图建模的流程的一致性边界是什么

我问在任何一个原子操作中必须应用什么规则。这被称为事务边界，在定义不变量（在原子操作的生命周期中必须始终为真的规则-从开始到结束）时，它是您的谋生之道

在我看来，医生/外科医生必须拥有n年的经验——对于特定的手术——这一规则是一个不变的规则，必须始终保持交易一致性（例如在执行手术时）。因此，应将其建模为单个聚合中的事务边界

因为聚合只能保证自身的一致性，所以它负责的不变量不应该泄漏到它之外。在我看来，假设医生是一个集合，一个单独的角色模型不应该负责医生模型本身应该负责的不变量

建立聚合到聚合的关系实际上只应在提供某些缺失信息时提供“帮助”。但这些规则以及如何解释这些信息应该在各自的集合中加以隔离

用户身份验证可能会出现另一种情况。您可能有一个带有

客户

模型的有界上下文，但是权限、身份验证和角色的详细信息非常庞大，需要一个完全独立的系统来处理。在这种情况下，您可能会为

用户角色和权限创建一个单独的有界上下文，并链接两个有界上下文。在这个场景中，您可以有一个域服务来处理两者之间的通信。使用操作调用
客户
根用户，并将域服务传递给某个用户，以显示双重分派，并让域服务解决该操作是否通过。但是在这种情况下，用户身份验证的责任根本不是
客户的责任。
Customer
根本不在乎（因为它本身无法保证交易），而是由
用户授权和角色来决定该做什么

来自：实施领域驱动设计-沃恩·弗农

正确设计的聚合是一种可以根据业务需要以任何方式修改的聚合，其不变量在单个事务中完全一致。在所有情况下，正确设计的有界上下文在每个事务中只修改一个聚合实例。更重要的是，如果不应用事务分析，我们就无法正确地对聚合设计进行推理

就使用的语言而言，请原谅，因为我不知道聚合是如何构造的，但它不是
doctor.scheduleSurgery（date）
？从您的帖子和功能performSurgery来看，听起来系统正在进行切割！我同意，我们可以从一个具体的用例中讨论使用的语言，但问题的焦点是何时需要对博士类（域角色）建模，何时不需要建模，