2014-09-25 37 views
6

REST有一个统一的接口约束,这是一个非常压缩的基于意见的格式。是否可以执行DDD和REST接口和语言映射?

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

DDD与CQRS(或没有它)是非常相似,据我所知。

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

是否可以将REST统一接口映射到由命令和查询以及域事件定义的域接口? (所以REST服务代码将自动生成。)

是否有可能链接的数据语义无处不在的语言映射? (这样你就不会需要定义非常类似的术语,只是发现和重用现有vocabs。)

请添加一个非常简单的映射示例您的答案,为什么是或为什么不!

+0

这让我想起了裸体物品(http://www.nakedobjects.org/)。我发现还有一些叫做restful objects的东西(http://restfulobjects.org/):http://www.infoq.com/articles/Intro_Restful_Objects – 2014-09-26 09:24:15

+0

实际上,命令,域事件等的属性不应该被隐藏。它们是代表领域模型界面的DTO。所以裸体对象完成了一些完全不同的事情。 RESTful对象得到了错误的映射:“在Restful Objects规范中,每个域对象都是资源”。但我没有更多帮助,我不想写出答案。 – inf3rno 2014-09-26 16:21:36

回答

9

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

在这种情况下具有至少有3个本体:

  • 域模型的通用语言(UL)
  • REST服务
  • 的专用词汇(ASO)连动开数据vocabs(LODO),其特定于应用的词汇使用

因此,我们有至少2个比对:

  • 的UL:ASO对准
  • 的ASO:LODO对准

我们的问题是关系到UL:ASO对齐,所以让我们来谈谈这些本体。

UL是面向对象的,因为我们正在讨论DDD和领域模型。所以大多数域对象entitiesvalue objects是真实的对象而不是数据结构。它的非面向对象的部分是DTO,如域模型接口上的command+domainEvent,query+resulterror

相比之下,ASO严格是程序性的,我们使用一套标准方法(程序)对资源(数据结构)进行操作。

所以从我的方面,我们都在谈论2个非常不同的事情,我们得到了以下选项:

  • 使面向ASO多个对象 - > RPC
  • 使UL较少面向对象 - >贫血领域模型
从我的角度,我们可以做以下的事情一点

所以:

  • 我们可以通过CRUD自动将实体映射到资源和命令,以便通过CRUD进行操作,例如HydraBundle可以对活动记录(我们可以使用DDD和无CQRS的方式进行操作)
  • 我们可以手动将命令映射到操作复杂的域模型

    • 操作POST transaction {...}可导致一个SendMoneyCommand{...}
    • 操作GET orders/123/total可以导致一个OrderTotalQuery{...}
  • 我们不能用一个复杂的域模型映射实体资源,因为我们必须定义新的资源来形容新服务或新实体的方法,例如

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

我认为这是不可能做这种本体对准投注ween DDD + CQRS和REST,但我不是这个话题的专家。我认为我们可以做的是创建具有资源类,属性和操作的特定于应用程序的词汇表,并将操作映射到命令/查询以及将属性映射到命令/查询属性。

1

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

首先我并不十分赞同

通过DDD定义域事件中去耦从 持久性细节的域模型一致。

我想你可能是混乱Event Sourcing ES与DDD,ES可与DDD可以使用,但它的很多可选其实你应该给它选择它作为您的持久性机制之前花了很多心思。

我们大部分的如果是如何REST和DDD是否相处的问题,?

我就可以拿,是他们相处,但是一般你不想通过REST接口暴露你的域模型,你想建立在它的抽象,然后暴露这一点。

您可以参考这个答案here,对于更多的细节。

但是我不能推荐足够的Implementing Domain-Driven Design书,第14章申请涉及您的关注相当程度。

我不能更彻底低于其账面解释它,因此你提到有:)

+0

“我认为您可能会将事件采购ES与DDD混淆” - 不需要,DDD必须将您的域模型与数据存储分离,或者我们正在讨论活动记录而不是域模型。使用域名事件是最好的方式。 “现在你的问题的大部分,是否REST和DDD相处如果是的话,怎么样?” 他们相处融洽。问题是关于是否可以基于领域模型自动生成REST部分... – inf3rno 2014-09-29 19:05:09