域驱动设计 – DDD / CQRS / ES使用图数据库实现聚合成员,也使用

我正在为我的应用程序建模通用授权子域.这些要求非常复杂,因为它需要处理多租户,分层组织结构,资源组,用户组,权限,用户可编辑权限等.它是RBAC(分配给角色的用户,具有权限的角色,权限可以执行命令)与基于声明的身份验证的混合体.

问题

在检查业务规则不变量时,我必须遍历权限“图”以找到用户对环境中的资源执行命令的权限.遍历深度在多个维度上是任意的.

我可以使用代码对此进行建模,但最好使用图形数据库来表示,因为此聚合上的查询/更新会更快.此外,它会降低代码本身的复杂性.但这需要图形数据库立即保持一致.

不过,我需要使用CQRS / ES,并启用分布式架构.

所以图数据库需要

>立即一致

这带来了一些缺点

>从事件存储加载事件时,我们每次都必须重建图数据库
>或者,我们必须介绍某种图形数据库快照
>与图表数据库通信时的开销

但它有优势

>降低执行复杂查询的复杂性
>复杂查询的解析速度比使用代码的速度快
>图表数据库非常适合这项工作

为什么提出此问题呢？

在我建模的其他聚合中,我经常有一个EntityList实例或EntityHierarchy实例.它们基本上是子实体的有序/分层集合.他们的实施是任意的.它们可以支持索引,键值对,动态数组等任何内容.只要它们实现我为它们声明的接口.我经常在这些实体(列表)上使用findById()或findByName()等方法.这些方法类似于可以在数据库上执行的方法,但它们是在内存中执行的.

那么,为什么不能实现这样一个可以绑定到数据库的列表呢？例如,我没有TMemoryEntityList,而是拥有TMySQLEntityList.在目前的情况下,可能需要实现一个存在于TOrgAuthPolicy聚合内的TGraphAuthorizationScheme.只要它的行为类似于集合,并且它可以迭代并支持定义的接口.

我正在使用Node.js上的JavaScript构建我的应用程序.这个叫做LevelGraph的内存实现.也许我也可以使用它.但是让我们继续吧.

提案

我知道在DDD术语中,基础设施不应泄漏到域中.这就是我想要阻止的.这也是我提出这个问题的原因之一,就是这是我第一次遇到这样的技术需求,我要求那些习惯于应对这类问题的人提出一些建议.

该集合的接口是IAuthorizationScheme.实现必须支持深度遍历,授权查找等.这是我正在考虑通过支持图形数据库来实现的接口.

序列 ：

1当用户要求执行命令时,我首先验证他.我找到他的组织,并要求OrgAuthPolicyRepository加载他的组织的相应OrgAuthPolicy.

> OrgAuthPolicyRepository从EventStore加载事件.
> OrgAuthPolicyRepository使用依赖注入的TGraphAuthorizationScheme实例创建一个新的OrgAuthPolicy.
> OrgAuthPolicyRepository将所有先前事件应用于OrgAuthPolicy,OrgAuthPolicy又调用图数据库上的查询以将GraphDatabase的状态与聚合同步.
>命令处理程序执行业务规则验证检查.其中一些可能包含对聚合的IAuthorizationScheme的检查.
>已验证业务规则,并分派域事件.
>聚合处理此事件,并将其应用于自身.这可能包括对IAuthorizationScheme的更改.
> eventBus将事件调度到读取端的所有侦听eventHandler.

示例：

在简历中

可以想象/希望使用外部数据库(例如图形数据库)实现实体,以便它们的实现更容易吗？如果是,是否有此类实施或指南的示例？如果没有,使用这种技术有什么缺点？