domain-driven-design - DDD/CQRS/ES 使用图形数据库实现聚合成员，也就是使用立即一致的 readModel 作为实体集合

Question

抽象的

我正在为我的应用程序建模一个通用授权子域。需求比较复杂，需要处理 Multi-Tenancy 、分层组织结构、资源组、用户组、权限、用户可编辑权限等。它是 RBAC(分配给角色的用户、具有权限的角色、执行命令的权限)与基于声明的身份验证的混合。

问题

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

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

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

所以图数据库需要

立即一致

这引入了一些缺点

当从event-store加载事件时，我们每次都要重建图数据库

或者，我们必须引入某种图形数据库快照

与图数据库通信时的开销

但它有优点

降低执行复杂查询的复杂性

复杂查询的解析速度比代码更快

图数据库非常适合这项工作

为什么这么问？

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

因此，为什么不实现一个可以绑定(bind)到数据库的列表呢？例如，而不是拥有 TMemoryEntityList ，我会有一个 TMySQLEntityList .在手头的情况下，也许有一个 TGraphAuthorizationScheme 的实现那将住在 TOrgAuthPolicy聚合将是可取的。只要它表现得像一个集合并且它是可迭代的并且支持定义的接口(interface)。

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

提议

我知道在 DDD 术语中，基础设施不应该泄漏到域中。这就是我试图阻止的。这也是我问这个问题的一个原因，是第一次遇到这样的技术需求，想请教处理过这种问题的人给点建议。

收藏界面为 IAuthorizationScheme .实现必须支持深度遍历、授权查找等。这是我正在考虑通过用图形数据库支持它来实现的接口(interface)。

序列 :

1 当用户要求执行命令时，我首先对他进行身份验证。我找到他的组织，并询问 OrgAuthPolicyRepository加载他的组织相应的 OrgAuthPolicy .

OrgAuthPolicyRepository从 EventStore 加载事件.

OrgAuthPolicyRepository创建一个新的 OrgAuthPolicy , 依赖注入(inject) TGraphAuthorizationScheme实例。

OrgAuthPolicyRepository将所有以前的事件应用于 OrgAuthPolicy ，依次调用图形数据库上的查询以同步 GraphDatabase 的状态与聚合。

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

业务规则已通过验证，并且已调度域事件。

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

eventBus 将事件分派(dispatch)给读取端的所有监听 eventHandler。

例子 :



在简历中

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

Answer 1

为了解决您的任务，我会考虑以下从上到下的变体:

通过使用安全框架或身份来降低任务复杂性
管理解决方案。一些现成的 identity management solution可能会做这项工作。如果它不查看框架以帮助您实现自己的框架。不幸的是，我对 Node.js 世界不太熟悉，无法提供建议
你随便。在 Java 世界中，这可能是 Apache Shiro或 Spring Security .从成本和安全角度来看，这可能是一个不错的选择

维护单一模型而不是 CQRS。这消除了一致性问题(如果您决定将
用于存储模型的资源)。根据我的理解
权限不应频繁更改，但会被访问
频繁地。这意味着您可以使用一种优化的模型
读取，避免一致性问题并维护 2 个模型。到
跟踪用户行为，您可以单独实现审计。
根据我的经验，安全审计可能需要一些额外的
最有可能不在您的数据模型中的数据。

用 CQRS 来做。在这里，我将首先考虑重新审视需求以找到接受 eventual consistency 的方法。而不是强一致性。这为实现打开了许多选项。

关于您是否应该使用引入专用图形数据库的问题，如果不了解您的领域、预算、所需的系统吞吐量和性能、现有基础设施、团队知识和设置等，则无法回答。您需要使用专用图形数据库估算解决方案的成本和没有它。我的补充是，除非权限管理是您项目的主要思想或您的项目足够成熟(按用户数量和研发能力)，否则专用数据库不太可能为您的任务支付成本。

要了解拥有专用图形数据库的好处，您现有的存储解决方案应该相反。这两篇文章很好地解释了可能带来的好处:

http://neo4j.com/developer/graph-db-vs-nosql/

http://neo4j.com/developer/graph-db-vs-rdbms/