是否可以執行DDD和REST接口和語言映射？

REST有一個統一的接口約束，這是一個非常壓縮的基於意見的格式。是否可以執行DDD和REST接口和語言映射？

你必須使用如HTTP，URI，MIME等標準...
你必須使用超鏈接。
您必須使用RDF詞彙來註釋數據和帶有語義的超鏈接。
所有這些都將客戶端與服務的實現細節分離。

DDD與CQRS（或沒有它）是非常相似，據我所知。

通過CQRS您定義了一個接口來與域模型進行交互。這個接口由命令和查詢類組成。
通過DDD，您可以定義域事件以將域模型與持久性詳細信息分離。
由DDD你有一個無處不在的語言每個有界的上下文表達的語義。
你完成所有這些工作，將領域模型與外界完全分離。

是否可以將REST統一接口映射到由命令和查詢以及域事件定義的域接口？（所以REST服務代碼將自動生成。）

是否有可能鏈接的數據語義無處不在的語言映射？（這樣你就不會需要定義非常類似的術語，只是發現和重用現有vocabs。）

請添加一個非常簡單的映射示例您的答案，爲什麼是或爲什麼不！

來源

2014-09-25 inf3rno

這讓我想起了裸體物品（http://www.nakedobjects.org/）。我發現還有一些叫做restful objects的東西（http://restfulobjects.org/）：http://www.infoq.com/articles/Intro_Restful_Objects – 2014-09-26 09:24:15

實際上，命令，域事件等的屬性不應該被隱藏。它們是代表領域模型界面的DTO。所以裸體對象完成了一些完全不同的事情。 RESTful對象得到了錯誤的映射：「在Restful Objects規範中，每個域對象都是資源」。但我沒有更多幫助，我不想寫出答案。 – inf3rno 2014-09-26 16:21:36

我不認爲這是可能的。有一個術語我相信描述了這個問題，它被稱爲ontology alignment。

在這種情況下具有至少有3個本體：

域模型的通用語言（UL）
REST服務
的專用詞彙（ASO）連動開數據vocabs（LODO），其特定於應用的詞彙使用

因此，我們有至少2個比對：

的UL：ASO對準
的ASO：LODO對準

我們的問題是關係到UL：ASO對齊，所以讓我們來談談這些本體。

UL是面向對象的，因爲我們正在討論DDD和領域模型。所以大多數域對象entities，value objects是真實的對象而不是數據結構。它的非面向對象的部分是DTO，如域模型接口上的command+domainEvent,query+result和error。

相比之下，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，但我不是這個話題的專家。我認爲我們可以做的是創建具有資源類，屬性和操作的特定於應用程序的詞彙表，並將操作映射到命令/查詢以及將屬性映射到命令/查詢屬性。

來源

2014-10-11 00:59:13 inf3rno

你在這裏提出了一些有趣的問題。

首先我並不十分贊同

通過DDD定義域事件中去耦從持久性細節的域模型一致。

我想你可能是混亂Event Sourcing ES與DDD，ES可與DDD可以使用，但它的很多可選其實你應該給它選擇它作爲您的持久性機制之前花了很多心思。

我們大部分的如果是如何REST和DDD是否相處的問題，？

我就可以拿，是他們相處，但是一般你不想通過REST接口暴露你的域模型，你想建立在它的抽象，然後暴露這一點。

您可以參考這個答案here，對於更多的細節。

但是我不能推薦足夠的Implementing Domain-Driven Design書，第14章申請涉及您的關注相當程度。

我不能更徹底低於其賬面解釋它，因此你提到有:)

來源

2014-09-29 05:46:01 Sudarshan

「我認爲您可能會將事件採購ES與DDD混淆」 - 不需要，DDD必須將您的域模型與數據存儲分離，或者我們正在討論活動記錄而不是域模型。使用域名事件是最好的方式。「現在你的問題的大部分，是否REST和DDD相處如果是的話，怎麼樣？」他們相處融洽。問題是關於是否可以基於領域模型自動生成REST部分... – inf3rno 2014-09-29 19:05:09

是否可以執行DDD和REST接口和語言映射？

回答

相關問題