我正在使用DDD构建应用程序。它是一个员工评估申请。作为域层的一部分，我有一个评估文件。该文档可以做什么取决于用户相对于评估文档所扮演的角色，还取决于文档的状态。
这些是域概念还是跨界关注-安全性？？？？
您如何向UI中继允许哪些动作？？？
最佳答案
这是一个棘手的问题。问题可能是您的业务专家已经习惯了Appraisal Document的概念，这是计算机前时代或他们已经习惯的旧应用程序的遗留物。但是，Appraisal Document仅仅是人们用来记录实际评估过程的计算机前时代的工具，但是它很可能不是真正在评估业务中实际出现的概念。例如，如果您用口对口沟通取代了Appraisal Document，则评估过程很可能只会改变很小，并且Appraisal Document上的那些安全隐患将转化为诸如“主管不得讲话”的政策。关于员工对其他员工的评价”或“总是得到第二意见”。
（我有时会在大多数医生已经习惯使用软件的医疗健康记录领域中看到一个相关问题，以致他们似乎将记录某些内容的电子HR与实际的治疗/诊断相混淆。 ）
为了解决这个问题，您的业务专家应该从Appraisal Document的概念中解放出来，并专注于实际的评估过程。正如您已经说过的那样，人们在评估过程中会扮演某些角色，例如，主管，参与者，员工，裁判，并且文档状态实际上是指过程中的一个概念（第二眼原则或类似原则）。这些角色和过程应在您的评估BC中明确而精确地建模，可能涉及传奇/长期运行的过程。这样也很清楚，那些将限制对Appraisal Document的访问的安全问题实际上是实际域中的约束，并且与您域中的各个角色和进程状态紧密相关。
评估BC的应用程序界面可以为使用相应角色的应用程序提供服务，例如，gradeEmployee(String supervisorId, String employeeId, Integer grade)
或viewAppraisal(String viewingSuperVisorId, String appraisalId)
或involveReferee(...)。
然后，评估BC的应用程序接口有责任确保实际允许采取这些行动；为此，它将调用域模型的业务方法，例如AppRaisalDomainService.mayPublishReport(supervisor, appraisal)
在您的应用程序中要做的只是将应用程序的用户映射到相应的supervisorId / employeeId。例如，您可能想看一下[IDDD_Samples] [1]存储库中Vaughn Vernon的“协作”有界上下文，其中人们具有诸如Moderator，Author等角色，以及协作上下文如何从其他相关BC使用。
最后，您可以在用户界面中向用户展示评估过程的当前状态。单个评估的“详细信息”页面将自动成为人们习惯的“评估文件”。您甚至可以通过“评估文档”或类似名称来授予UI视图的权限，以使您的用户满意，如果他们打印出该视图，他们实际上就将这样的文档握在手中。但是，在基础应用程序中，访问权限不仅限于“评估文件”，还限于基础评估过程，并且访问限制是域概念。