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