DDD/CQRS/ES使用图数据库实现聚合成员,也使用立即一致的readModel作为实体集合
Lud*_*c C 7 domain-driven-design graph-databases cqrs event-sourcing
抽象
我正在为我的应用程序建模通用授权子域.这些要求非常复杂,因为它需要处理多租户,分层组织结构,资源组,用户组,权限,用户可编辑权限等.它是RBAC(分配给角色的用户,具有权限的角色,权限可以执行命令)与基于声明的身份验证的混合体.
问题
在检查业务规则不变量时,我必须遍历权限"图"以找到用户对环境中的资源执行命令的权限.遍历深度在多个维度上是任意的.
我可以使用代码对此进行建模,但最好使用图形数据库来表示,因为此聚合上的查询/更新会更快.此外,它会降低代码本身的复杂性.但这需要图形数据库立即保持一致.
不过,我需要使用CQRS/ES,并启用分布式架构.
所以图数据库需要
- 立即一致
这带来了一些缺点
- 从事件存储加载事件时,我们每次都必须重建图数据库
- 或者,我们必须介绍某种图形数据库快照
- 与图形数据库通信时的开销
但它有优势
- 降低执行复杂查询的复杂性
- 复杂查询的解析速度比使用代码更快
- 图表数据库非常适合这项工作
为什么提出此问题呢？
在我建模的其他聚合中,我经常有一个EntityList实例或EntityHierarchy实例.它们基本上是子实体的有序/分层集合.他们的实施是任意的.它们可以支持索引,键值对,动态数组等任何内容.只要它们实现我为它们声明的接口.我经常甚至在这些实体(列表)上有findById()或类似的方法findByName().这些方法类似于可以在数据库上执行的方法,但它们是在内存中执行的.
那么,为什么不能实现这样一个可以绑定到数据库的列表呢？例如,TMemoryEntityList我会有一个,而不是一个TMySQLEntityList.在目前的情况下,可能需要实现一个TGraphAuthorizationScheme可以存在于TOrgAuthPolicy聚合内部的实现.只要它的行为类似于集合,并且它可以迭代并支持定义的接口.
我正在使用Node.js上的JavaScript构建我的应用程序.这个名为LevelGraph的内存实现.也许我也可以使用它.但是让我们继续吧.
提案
我知道在DDD术语中,基础设施不应泄漏到域中.这就是我想要阻止的.这也是我提出这个问题的原因之一,就是这是我第一次遇到这样的技术需求,我要求那些习惯于应对这类问题的人提出一些建议.
集合的接口是IAuthorizationScheme.实现必须支持深度遍历,授权查找等.这是我正在考虑通过支持图形数据库来实现的接口.
序列 :
1当用户要求执行命令时,我首先验证他.我找到他的组织,并要求OrgAuthPolicyRepository加载他的组织的相应OrgAuthPolicy.
该
OrgAuthPolicyRepository载荷从事件EventStore.将
OrgAuthPolicyRepository创建一个新的OrgAuthPolicy,具有依赖注入TGraphAuthorizationScheme实例.该
OrgAuthPolicyRepository应用所有以前的事件的OrgAuthPolicy,这进而调用图形数据库查询同步的状态GraphDatabase与集料.命令处理程序执行业务规则验证检查.其中一些可能包括对聚合的检查
IAuthorizationScheme.已验证业务规则,并分派域事件.
聚合处理此事件,并将其应用于自身.这可能包括改变
IAuthorizationScheme.eventBus将事件调度到读取端的所有侦听eventHandler.
示例:
在简历中
可以想象/希望使用外部数据库(例如图形数据库)实现实体,以便它们的实现更容易吗？如果是,是否有此类实施或指南的示例？如果没有,使用这种技术有什么缺点？
为了解决您的任务，我会从上到下考虑以下变体：
- 通过采用安全框架或身份管理解决方案来降低任务复杂性。一些现有的开箱即用的身份管理解决方案可能可以完成这项工作。如果不看一下框架来帮助您实现自己的框架。不幸的是，我对 Node.js 世界不太熟悉，无法为您提供建议。在 Java 世界中，可能是Apache Shiro或Spring Security。从成本和安全角度来看，这可能是一个不错的选择
- 维护单一模型而不是 CQRS。这消除了一致性问题（如果您决定使用单独的资源来存储模型）。据我了解，权限不应频繁更改，但会经常访问。这意味着您可以使用一种针对读取进行优化的模型，避免一致性问题并维护 2 个模型。要跟踪用户行为，您可以单独实施审核。根据我的经验，安全审计可能需要一些额外的数据，这些数据很可能不在您的数据模型中。
- 使用 CQRS 进行操作。在这里，我首先考虑重新审视需求，找到一种接受最终一致性而不是强一致性的方法。这为实施提供了许多选择。
关于您是否应该使用引入专用图数据库的问题，如果不了解您的领域、预算、所需的系统吞吐量和性能、现有基础设施、团队知识和设置等，则无法回答。您需要使用专用图数据库来估计解决方案的成本，并没有它。我的填充是，除非权限管理是您项目的主要思想，或者您的项目足够成熟（根据用户数量和研发能力），否则专用数据库不太可能偿还您的任务成本。
要了解拥有专用图形数据库可能带来的好处，您应该将现有的存储解决方案放在相反的位置。这两篇文章很好地解释了这样的好处：
| 归档时间： |
|
| 查看次数： |
592 次 |
| 最近记录： |