Domain Driven Design - Domain or Security

This is a somewhat tricky question. The problem might be that your business experts have already settled with the concept of an Appraisal Document, which is a relic of pre-computer eras or old applications that they are already used to. However, an Appraisal Document is a merely a pre-computer era tool that people use to document the actual appraisal process, but it is most probably not a concept that actually occurs in the real business of appraisals. For example, if you replaced the Appraisal Document with mouth-to-mouth communication, your appraisal process would most probably change only very little, and those security concerns on the Appraisal Document would translate to policies such as "a supervisor must not talk about an employee's appraisal with other employees" or "always get a 2nd opinion".

(I sometimes see a related problem in the area of medical health records where most doctors are already used to software, such that they seem to confuse the Electronic HR -- that documents something -- with the actual treatment/diagnosis -- to be documented.)

To solve this, your business experts should liberate from the concept of an Appraisal Document and focus on the actual appraisal process. As you said already, there are certain roles that people play during the appraisal, e.g., Supervisor, Participant, Employee, Referee, and the document status actually refers to a concept in the process (2nd eye principle or similar). These roles and the process should be modeled explicitly and precisely in your Appraisal BC, possibly involving a saga/long running process. It then also becomes clear that those security concerns that shall restrict access the Appraisal Document are actually constraints within the actual domain and are strongly tight to the respective roles and process state in your domain.

The application interface of your Appraisal BC could offer services to your application that uses the respective roles, e.g., gradeEmployee(String supervisorId, String employeeId, Integer grade) or viewAppraisal(String viewingSuperVisorId, String appraisalId) or involveReferee(...). It is then the duty of the application interface of the Appraisal BC to ensure that the actions are actually allowed; for, it would call business methods of the domain model, e.g. AppRaisalDomainService.mayPublishReport(supervisor, appraisal)

All that is left to do in your Application is to map the users of your application to the respective supervisorId/employeeId. For an example, you may want to take a look at Vaughn Vernon's "Collaboration" bounded context in the [IDDD_Samples][1] repository, where people have roles such as Moderator, Author etc, and how the collaboration context is used from other related BCs.

Finally, in your UI you can then present the current state of the appraisal process to your users. The "details" page of a single appraisal will automagically become the "Appraisal Document" people are used to. You can even entitle your UI view by "Appraisal Document" or similar in order to satisfy your users, and if they print out that view, they actually hold such a document in their hand. In the underlying application, however, access is not restricted to the "Appraisal Document", but rather to the underlying appraisal process, and the access restrictions are a domain concept.