我正在寻找一些关于何时必须在域模型中明确建模角色的指南。
我将在这里借助一个例子解释我目前的立场。
假设我们正在建立医疗保健系统，业务要求说明
＆＃34;只有具有3年以上经验且具有一定经验的医生 资格可以进行手术＆＃34;
在这种情况下，很明显，做手术的行为只能由扮演医生角色的人执行，而医生需要满足某些先决条件才能执行手术
docter.performSurgery()
基本上所有医生都不一样
此方法可能会检查是否符合前提条件
因此，在上述情况下，我将明确地为角色建模。
现在让我们考虑替代方案。
只有管理员可以批准资金转帐
在上述情况下，我不发现需要在域中对此角色进行建模，因为它们没有规则区分我的域中的一个管理员。
任何拥有admin权限的person / userlogin都可以执行此操作，我宁愿将其设计到我的安全基础架构中并确保
仅当当前登录的用户具有ADMIN权限时，才会调用在应用程序层上调用的 approveTransfer()方法。
所以＆＃34;域模型＆＃34;我的意思是像Account类这样的类不知道这个规则，这是通过AOP或可能是AccountService类等在应用程序层中编写的。
智者对此有何看法？ ：）
答案 0 :(得分：0)
在设计聚合时，我总是问自己一个重要的问题。
我问在任何一个原子操作期间必须应用什么规则。这被称为事务边界，在定义不变量时它是你的面包（规则在原子操作的生命周期中必须始终为真 - 从开始到结束）。
在我看来，医生/外科医生必须具有多年经验的规则 - 对于特定手术 - 是一种必须始终在事务上保持一致的不变量（例如在进行手术时）。因此，它应该被建模为单个聚合中的事务边界。
因为聚合只能保证其自身的一致性，所以它负责的不变量不应该泄露在它之外。在我看来，假设医生是一个聚合体，一个单独的角色模型不应该对医生的模型本身应该负责的不变量负责。
聚合到聚合关系的确应该只是为了提供“帮助”来提供一些缺失的信息。但是规则以及如何解释这些信息应该在其各自的汇总中进行隔离。
用户身份验证可能会出现单独的情况。您可能拥有带有Customer模型的有界上下文，但权限，身份验证和角色的详细信息非常庞大，需要一个完全独立的系统来处理。在这种情况下，您最终可能会为User Roles and Permission创建一个单独的有界上下文并链接两个有界上下文。在这种情况下，您可以使用域服务来处理两者之间的通信。使用操作调用Customer root并传入域服务以获得一些显示双重调度的意图，并让域服务解析该操作是否通过。但在这种情况下，用户身份验证的职责根本不是Customer。 Customer根本不关心（因为它本身不能保证交易），而User Auth and Roles最多可以决定做什么。
来自：实施域驱动设计 - Vaughn Vernon
正确设计的聚合是可以以任何方式修改的聚合，其不变量在单个事务中完全一致。并且在所有情况下，正确设计的Bounded Context仅为每个事务修改一个Aggregate实例。更重要的是，我们无法在不应用事务分析的情况下正确推理聚合设计。