是否可以进行DDD和REST接口和语言映射？

Question

REST具有统一的接口约束，这是一种非常压缩的基于意见的格式。

• 您必须使用HTTP，URI，MIME等标准......
• 您必须使用超链接。
• 您必须使用RDF词汇来注释带语义的数据和超链接。
• 您可以执行所有这些操作，将客户端与服务的实现细节分离。

根据我的理解，使用CQRS（或没有它）的DDD非常相似。

• 通过CQRS，您可以定义与域模型交互的接口。该接口由命令和查询类组成。
• 通过DDD，您可以定义域事件以将域模型与持久性详细信息分离。
• 通过DDD，每个有界上下文都有一种无处不在的语言，表达了语义。
• 您可以将所有这些完全与外部世界分离。

是否可以将REST统一接口映射到由命令和查询以及域事件定义的域接口？ （因此，REST服务代码将自动生成。）

是否可以将链接数据语义映射到无处不在的语言？ （所以你不需要定义非常相似的术语，只需找到并重用现有的词汇。）

请在答案中添加一个非常简单的映射示例，为什么不是，为什么不呢！

Answer 1

我不认为这是可能的。我认为有一个术语描述了这个问题，它被称为ontology alignment。

在这种情况下，至少有3个本体：

• 域模型的普遍存在的语言（UL）
• REST服务的应用程序特定词汇（ASO）
• 应用程序特定词汇使用的链接开放数据词汇（LODO）

所以我们至少有2个路线：

• UL：ASO路线
• ASO：LODO路线

我们的问题与UL：ASO对齐有关，所以我们来谈谈这些本体。

UL是面向对象的，因为我们讨论的是DDD和域模型。因此，大多数域对象entities，value objects都是真实对象，而不是数据结构。非面向对象的部分是域模型接口上的command+domainEvent，query+result和error等DTO。

相比之下，ASO是严格程序性的，我们使用一套标准方法（程序）操纵资源（数据结构）。

所以从我的角度来看，我们谈论的是两个非常不同的事情，我们得到了以下选择：

• 使ASO更加面向对象 - ＆gt; RPC
• 使UL不那么面向对象 - ＆gt;贫血领域模型

因此，从我的观点来看，我们可以做以下事情：

• 我们可以通过CRUD自动将实体映射到资源和命令到操作，例如HydraBundle使用活动记录执行此操作（我们可以使用DDD和没有CQRS执行相同操作）

• 我们可以手动将命令映射到复杂域模型的操作

  • 操作POST transaction {...}可以产生SendMoneyCommand{...}
  • 操作GET orders/123/total可以产生OrderTotalQuery{...}

• 我们无法通过复杂的域模型将实体映射到资源，因为我们必须定义新资源来描述新服务或新实体方法，例如

  • 操作POST transaction {...}可能会导致account.sendMoney(anotherAccount, ...)
  • 操作GET orders/123/total可以导致读取数据库上的SQL查询，而不会触及单个实体

我认为在DDD + CQRS和REST之间进行这种本体对齐是不可能的，但我不是这个主题的专家。我认为我们可以做的是创建一个包含资源类，属性和操作的特定于应用程序的词汇表，并将操作映射到命令/查询以及将属性映射到命令/查询属性。

Answer 2

你在这里提出了一些有趣的问题。

首先，我不太同意

  

通过DDD，您可以定义域事件以将域模型与域分离   持久性细节。

我认为你可能会将Event Sourcing ES与DDD混淆，ES可以与DDD一起使用，但它实际上非常可选，在选择它作为你的持久性机制之前你应该多考虑一下。

现在，您的大部分问题是REST和DDD是否相处如果是，如何？

我接受它，是的，它们相处得很好，但是通常你不想通过REST接口暴露你的域模型，你想在它上面构建一个抽象，然后公开它。

您可以参考此答案here，了解更多细节。

但是，我不能推荐Implementing Domain-Driven Design本书，第14章应用程序处理您对公平程度的关注。

我无法比书更彻底地解释它，因此在那里引用你：）