域驱动设计与图数据库答案

【问题标题】：Domain Driven Design alongside Graph database域驱动设计与图数据库
【发布时间】：2013-12-15 21:03:18
【问题描述】：

我一直在网上搜索与使用域驱动设计和图形数据库（例如 Neo4j）相关的任何信息，我不得不说没有太多信息可查！

我的主要查询与两者之间的明显重叠出现，即图形数据库和 DDD 都对域进行建模，但是图形数据库只保存状态，而不是行为。我不确定如何将两者混合在一起......我该如何混合行为？也许使用域服务？为每个图节点创建域实体/值似乎是一种添加行为的荒谬方式。

有什么想法吗？

【问题讨论】：

【解决方案1】：

它们可以以图形数据库通常用于“读取”端的方式共存。

人们有时所做的是将 CQRS 应用于给定的有界上下文，并在有意义的地方使用 Graph DB 进行投影。

【讨论】：

【解决方案2】：

这取决于您的有界上下文以及您如何使用数据。

数据消耗有界上下文：

您可以使用域服务来隐藏技术细节。在著名的dddsample 中有一个很好的例子。他们使用 RoutingService 将路由知识（被称为路由有界上下文）与货物预订有界上下文分开。

域服务背后的实现可能甚至不是使用 ddd 开发的。您可以以图形数据库友好的方式开发它。

产生有界上下文的数据：

CQRS 可能是解决领域模型和图数据库之间差距的一个很好的解决方案。在这种情况下，域模型用于生成计算的节点和关系。

【讨论】：

让我看看我是否理解......你建议我可以使用CQRS，以便我可以使用图形数据库作为查询模型和域模型作为命令模型？如果是这种情况，我仍然不确定域（命令）和图（查询）之间的交互......域模型是否仍会更新传统数据存储（很可能是关系数据库），然后通知图以便它可以反映变化。这并不能真正弥合行为（由域提供）和状态（由图提供）之间的差距。我误会了吗？
域状态可以存储在纯 EventSourcing 解决方案中，也可以以序列化形式存储在键/值存储中。然后根据您的查询需求将事件非规范化为 RDBMS、图形数据库或其他任何内容。