3

我使用 CouchDB，这是一个面向文档的数据库，将数据存储为 JSON 文档。我在后端使用 Javascript，所以我可以直接存储 JS 对象。目前，我在存储在 CouchDB 中的模型和我的域层之间有直接映射。我认为这不是一件好事，因为我完全依赖这个数据库。

例子

我有 2 个实体用户和项目。一个用户可以有多个项目，这些模型在数据库中表示为单独的文档：

用户文档 

{
  "_id": "1",
  "entity": "user"
}

项目文档
关系由属性user_id引用。

{
  "_id": "2",
  "entity": "project",
  "user_id": "1",
  "name": "project1"
}

// other project document
{
  "_id": "3",
  "entity": "project",
  "user_id": "1",
  "name": "project2"
}

我的问题是：
我应该在层之间保持这种方便的映射，还是应该创建一个抽象层，将模型从数据库转换为域对象？

更方便的用户域对象示例：

// _id property is replaced by id
// entity property is removed
// projects relations stand in a projects array
{
  id: "1",
  projects: [
   { id: "2", name: "project1"},
   { id: "2", name: "project1"}
  ]
}

注意：我想阅读 Eric Evans 的《领域驱动设计》一书。也许它可以帮助我了解如何管理此类模型抽象。

4

2 回答 2

2

恕我直言，这个问题与 DDD 没有太大关系，但我还是想回答它；-)

我肯定会将数据库对象转换为域对象。原因很简单：如果你改变了底层数据存储，你的对象就会改变，然后你将不得不因为技术原因更新你的域代码。

除此之外，数据库对象确实包含的内容比领域感兴趣的要多。这是摆脱它们的另一个原因：为您的域对象建模，使它们干净并按照您的期望行事。

此外，您希望能够轻松地测试您的域对象。如果它们包含所有数据库的东西，这会变得不必要地困难。

长话短说：不要在域层中使用数据库对象。

于 2017-12-19T18:10:23.713 回答
1

我认为这个问题涉及很多 DDD。
你在为什么而奋斗的是聚合。使用 nosql 数据库，文档应包含聚合。
对同一聚合中的实体使用不同的文档将具有持久化聚合对应于存储的多个文档的效果，这可能会独立失败（导致数据损坏）。
相反，DDD 聚合是域的事务边界，聚合的持久性必须是原子操作。

关于技术方面的东西，如果依赖将它们从域模型中删除是很好的等等......
但是如果离开它们会导致更多问题然后找到一种方法将它们从域中隐藏起来。所以这取决于领域的规模。

有关更多信息，这可能会有所帮助：为什么将命令和事件限制为一个聚合？CQRS + ES + DDD

于 2017-12-20T00:21:58.250 回答