在软件系统中，角色的定义一般在用户管理系统中完成，在应用系统中使用，一般情况下，可以针对不同的软件功能，为用户定义不同的角色，然后角色再关联一定的功能。这种定义方式，决定了用户与角色的关系是静态关系，可以满足一定的需求，但如果用户与角色之间存在动态关系，角色的定义需要在特定的上下文中完成，这种定义方式就不能满足要求了。
我们看一个例子。在某个审批流程中，涉及到外审，也就是请组织之外的专家进行评审，在组织的用户管理中，可以为每位外审专家创建用户，用户所关联的角色是“外审专家”，这样，可以通过这个角色得到所有的外审专家，从中挑选某位专家进行评审。当我们创建审批流程时，“外部专家评审”可以作为一个环节，这个环节的权限是“外审专家”，这种情况就属于静态关系，流程中涉及的角色与在用户管理系统中定义的角色是一致的。然而，如果在流程中涉及到多重审批，比如一审和二审，在一审和二审中都要涉及到外审专家，在流程上下文内，“一审外审专家”和“二审外审专家”是两个角色，但对应到用户管理系统中，都属于“外审专家”一种角色。我们使用用户管理系统中的“外审专家”角色进行选择，但在流程处理时，需要使用流程内部角色“一审外审专家”和“二审外审专家”进行内部的处理，这两个角色只能在流程上下文内部定义，不能在用户管理系统中使用通用角色进行定义。
上面这种情况在应用系统中非常常见，但经常被忽视，忽视的结果是容易造成理解上的混乱。解决的办法是在限界上下文内部定义角色，如果需要与用户管理中的角色对应，增加相应的翻译机制，将上下文内部的角色与用户管理中的角色对应。
如果感觉这种情况不好理解，可以想象一下演员的角色，一个演员可能是“一线男星”，这个角色类似于用户管理系统中定义的角色，但某部影片选角时，可以根据这个角色来挑选，一旦入选，到了具体的影片中，就变成“男一号”了，而到了另一部影片中，可能是“男二号”，也可能是友情出演的“客串角色”。具体的影片就是特定的限界上下文。