相关疑难解决方法(0)

我们正在尝试使用DDD原则对基于RBAC的用户维护系统进行建模.我们确定了以下实体:

Authorization is an Aggregate Root with the following:
    User   (an entity object)
    List<Authority>    (list of value objects)

Authority contains the following value objects:
    AuthorityType (base class of classes Role and Permission)
    effectiveDate

Role contains a List<Permission>
Permission has code and description attributes

在典型的场景中,授权绝对是聚合根,因为用户维护中的所有内容都围绕着这一点(例如,我可以授予用户一个或多个权限,即角色或权限)

我的问题是:角色和权限怎么样？它们也是各自背景下的聚合根吗？(即我有三种情境,授权,角色,许可).虽然可以在一个上下文中组合所有,但是角色不会太重,因为它将作为授权"对象图"的一部分加载吗？

我将我的系统分解为(至少)两个有限的背景:学习设计和调查计划.

在研究设计背景下有一个名为"主题"(面试的潜在主题)的概念.我们还维护该领域的受试者和人群之间的关联.

现在,在调查计划中,我们还需要(一些)关于该主题的信息(例如:用于计划访问,或者甚至用于预期选择的问卷,以防该受试者所属的人口事先已知).

所以,在这两种情况下我都需要这个"主题".

我应该采取什么方法？有一个共享内核,正如Eric Evans DDD一书中所解释的那样？我不介意(至少现在)让两个上下文共享同一个数据库.

或者......我应该去纯粹的微服务吗？含义:这两个不能/不应该共享数据库...,在这种情况下,我可能必须通过事件传递去镜像/复制路由:https://www.infoq.com/news/2014/11 /共享数据-有界上下文

对于上述情况,有关哪一个更好的想法？

谢谢!