domain-driven-design - 领域驱动设计——领域或安全

Question

我正在使用 DDD 构建应用程序。它是一个员工评估应用程序。作为领域层的一部分，我有一份评估文件。可以对此文档执行的操作取决于用户在评估文档中扮演的角色，但也取决于文档状态。

这些是域概念还是横切关注点 - 安全性？？？

您如何将允许的操作传递给 UI？？？

Answer 1

这是一个有点棘手的问题。问题可能是您的业务专家已经接受了 Appraisal Document 的概念。 ，这是他们已经习惯的前计算机时代或旧应用程序的遗留物。但是，Appraisal Document仅仅是一个前计算机时代的工具，人们用来记录实际评估过程，但它很可能不是实际评估业务中实际出现的概念。例如，如果您替换了 Appraisal Document通过口对口的交流，您的评估过程很可能只会发生很小的变化，而那些关于 Appraisal Document 的安全问题将转化为诸如“主管不得与其他员工谈论员工的评估”或“总是征求第二意见”之类的政策。

(我有时会在大多数医生已经习惯使用软件的医疗健康记录领域看到一个相关问题，以至于他们似乎混淆了电子 HR——记录一些东西——与实际治疗/诊断——记录在案。)

要解决这个问题，您的业务专家应该从 Appraisal Document 的概念中解放出来。并专注于实际的评估过程。正如您已经说过的，人们在评估过程中扮演着某些角色，例如主管、参与者、员工、裁判，而文件状态实际上是指过程中的一个概念(第二只眼原则或类似的)。这些角色和过程应该在您的评估 BC 中明确和精确地建模，可能涉及一个传奇/长期运行的过程。然后也很清楚，那些限制访问 Appraisal Document 的安全问题实际上是实际领域内的约束，并且对您领域中的各个角色和流程状态非常严格。

您的 Appraisal BC 的应用程序接口(interface)可以为使用相应角色的应用程序提供服务，例如， gradeEmployee(String supervisorId, String employeeId, Integer grade)或 viewAppraisal(String viewingSuperVisorId, String appraisalId)或 involveReferee(...) .然后，评估 BC 的应用程序接口(interface)的职责是确保这些操作实际上是允许的；因为，它将调用域模型的业务方法，例如AppRaisalDomainService.mayPublishReport(supervisor, appraisal)

在您的应用程序中剩下要做的就是将您的应用程序的用户映射到相应的 supervisorId。/employeeId .例如，您可能想查看 [IDDD_Samples][1] 存储库中 Vaughn Vernon 的“协作”限界上下文，其中人们具有诸如 Moderator 之类的角色。 , Author等等，以及其他相关 BC 如何使用协作上下文。

最后，在您的用户界面中，您可以向用户展示评估过程的当前状态。单次鉴定的“详情”页面会自动变成人们习惯的“鉴定文档”。您甚至可以通过“评估文档”或类似的方式为您的 UI View 命名，以满足您的用户，如果他们打印出该 View ，他们实际上手中拿着这样的文档。而在底层应用中，访问权限不限于“评估文档”，而是底层评估流程，访问限制是一个领域概念。