Domain driven design DDD/CQRS/ES使用图形数据库aka实现聚合成员，使用立即一致的readModel作为实体集合 摘要

我正在为我的应用程序建模一个通用授权子域。需求相当复杂，因为它需要处理多租户、分层组织结构、资源组、用户组、权限、用户可编辑权限等。它是RBAC（分配给角色的用户、拥有权限的角色、可以执行命令的权限）和基于声明的身份验证的混合体

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

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

尽管如此，我仍然需要使用CQRS/ES，并启用分布式体系结构

因此，需要创建图形数据库

• 立即一致

这带来了一些缺点

• 从事件存储加载事件时，每次都必须重建图形数据库
• 或者，我们必须引入某种图形数据库快照
• 与图形数据库通信时的开销

但它也有优势

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

为什么要问这个问题？ 在我建模的其他聚合中，我通常有一个

EntityList

实例或

EntityHierarchy

实例。它们基本上是子实体的有序/分层集合。它们的实施是任意的。它们可以支持任何东西，从索引、键值对、动态数组等等，只要它们实现我为它们声明的接口。我甚至经常在这些实体（列表）上使用类似于

findById（）

或

findByName（）

的方法。这些方法类似于可以在数据库上执行的方法，但它们是在内存中执行的

因此，为什么不实现这样一个可以绑定到数据库的列表呢？例如，我没有使用

TMemoryEntityList

，而是使用

TMySQLEntityList

。在目前的情况下，可能需要一个

TGraphAuthorizationScheme

的实现，它将位于

TOrgAuthPolicy

集合中。只要它的行为像一个集合，并且它是可移植的，并且支持定义的接口

我正在Node.js上使用JavaScript构建我的应用程序。有一个在内存中实现的称为。也许我也可以用这个。但让我们继续

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

集合的界面是

IAuthorizationScheme

。实现必须支持深度遍历、授权查找等。这是我正在考虑通过使用图形数据库支持来实现的接口

顺序：

1当用户请求执行命令时，我首先对其进行身份验证。我找到他的组织，并要求

OrgAuthPolicyRepository

加载其组织相应的

OrgAuthPolicy

OrgAuthPolicyRepository

从

EventStore

加载事件

OrgAuthPolicyRepository

创建一个新的

OrgAuthPolicy

，并注入一个依赖项

TGraphAuthorizationScheme

实例

OrgAuthPolicyRepository

将所有以前的事件应用于

OrgAuthPolicy

，后者依次调用图形数据库上的查询，以将

GraphDatabase

的状态与聚合同步

命令处理程序执行业务规则验证检查。其中一些可能包括使用聚合的

IAuthorizationScheme

进行检查

已验证业务规则，并已调度域事件

聚合处理此事件，并将其应用于自身。这可能包括对

IAuthorizationScheme

的更改

eventBus将事件分派给读取端的所有侦听EventHandler

例如：

简历中

---

是否可以/希望使用外部数据库（例如图形数据库）来实现实体，从而使其实现更容易？如果有，是否有此类实施的示例或指南？如果不是，使用这样的技术有什么缺点？

为了解决你的任务，我会考虑下面的变型自上而下：

通过使用安全框架或身份验证降低任务复杂性 管理解决方案。一些现成的东西可能会做这项工作。如果它不考虑框架来帮助您实现自己的。不幸的是，我对Node.js world知之甚少 你有。在Java世界中，这可能是或。从成本和安全角度来看，这可能是一个不错的选择

维护单一模型，而不是CQR。这消除了一致性问题（如果您决定使用单独的 存储模型的资源）。据我了解 权限不应经常更改，但会被访问 频繁地这意味着您可以使用一款针对以下方面进行优化的车型： 读取，避免一致性问题