领域驱动设计 - 领域或安全性

Question

领域驱动设计 - 领域或安全性

domain-driven-design

3

我正在使用DDD构建一个应用程序，它是一个员工评估应用程序。作为领域层的一部分，我有一个评价文档。对于这个文档可以做什么取决于用户在评价文档方面扮演的角色，但也取决于文档状态。

这些是领域概念还是交叉关注点-安全性？

如何向UI传达允许的操作？

- David

领域驱动设计中的安全性 http://www.utwente.nl/ewi/trese/graduation_projects/2008/Uithol.pdf - Soren

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Alexander Langer · Accepted Answer

这是一个有点棘手的问题。问题可能在于您的业务专家已经接受了“评估文档”的概念，这是计算机出现之前或他们已经习惯的旧应用程序的遗物。然而，“评估文档”仅仅是人们用来记录实际评估过程的一种计算机时代之前的工具，但它很可能不是实际评估业务中真正存在的概念。例如，如果您用口头沟通替换“评估文档”，那么您的评估过程很可能只会发生非常小的变化，并且对“评估文档”的安全关注将转化为政策，例如“主管不得与其他员工谈论员工的评估”或“始终要获得第二个意见”。

（我有时在医疗保健记录领域看到一个相关的问题，在那里，大多数医生已经习惯使用软件，以至于他们似乎将电子人力资源（记录某些东西）与实际的治疗/诊断 - 将要记录的内容 - 混淆了。）

为解决这个问题，您的业务专家应该从“评估文档”的概念中解放出来，专注于实际的评估过程。正如您已经提到的，人们在评估过程中扮演着某些角色，例如主管、参与者、员工、裁判等，文档状态实际上指的是流程中的一个概念（第二看法原则或类似概念）。这些角色和流程应该在您的评估 BC 中得到明确而准确的建模，可能涉及 saga/长时间运行的流程。然后也变得清楚了，那些限制对“评估文档”的访问的安全关注实际上是该领域内部的约束，并且与该领域中各自的角色和流程状态密切相关。

您的评估 BC 的应用程序接口可以向使用相应角色的应用程序提供服务，例如 gradeEmployee(String supervisorId, String employeeId, Integer grade) 或 viewAppraisal(String viewingSuperVisorId, String appraisalId) 或 involveReferee(...)。然后，评估 BC 的应用程序接口的职责是确保这些操作是实际允许的；因为它会调用领域模型的业务方法，例如 AppRaisalDomainService.mayPublishReport(supervisor, appraisal) 在您的应用程序中所要做的就是将您应用程序的用户映射到相应的supervisorId/employeeId。例如，您可以查看 Vaughn Vernon 的“Collaboration”限界上下文在[IDDD_Samples][1]存储库中的示例，人们担任角色如Moderator、Author等，以及协作上下文如何从其他相关 BC 中使用。

[1]:https://github.com/VaughnVernon/IDDD_Samples "IDDD_Samples"

最后，在您的用户界面中，您可以向用户展示评估过程的当前状态。单个评估的“详细信息”页面将自动变成人们熟悉的“评估文档”。您甚至可以通过类似“评估文档”的方式来命名您的UI视图，以满足您的用户需求。如果他们打印出该视图，他们实际上就拥有了这样一份文件。然而，在底层应用程序中，访问并不仅限于“评估文档”，而是针对底层评估过程进行控制，并且访问限制是一个领域概念。