【问题标题】:DDD external entity referenceDDD 外部实体引用
【发布时间】:2018-04-09 13:36:02
【问题描述】:

我有一个名为 Project 的 aggregateRoot。

这个项目可以有一个名为 GitRepository 的子实体。此实体表示对外部 git 存储库(如 Github、Bitbucket)的访问。

这是一个如何查看我的持久数据的示例(我使用 NoSql DB):

Project {
  id: String
  name: String
  GitRepository: GitRepository {
    externalRepoId: String // e.g. reference to the external github repo ID
    externalToken: String
}

GitRepository 实体包含允许我从此类外部服务(例如存储库名称或协作者)检索更多数据的属性。

当我有外部引用时,我不明白应该如何存储聚合根(我想我应该存储 Github 的外部 ID 引用)。但是我如何创建完整的 AR 来填充数据(合作者、存储库名称……)。

这是从外部服务获取数据后我的聚合根应该如何显示的示例。

Project {
  id: String
  name: String
  gitRepository {
    externalRepoId: String
    externalToken: String
    repoName: String
    collaborators: List []
    repoCreatedAt: Date
    ...
  }
}

在这种情况下,我的数据库中的模型化与我的域模型不同。有效吗?

PS:另一种选择是复制数据并存储我可以从 Github 获得的所有信息,但在这种情况下我可能会出现不一致(如果用户在外部服务上更新其数据)

【问题讨论】:

标签: web-services model architecture entity domain-driven-design


【解决方案1】:

我真的会考虑外部存储库是否是与内部存储库不同的聚合根。我知道说它们是同一件事在意识形态上似乎更简单,但它们显然不是。为您的项目打造“完整 AR”的想法不应该包括可以在您的应用程序之外更改的内容。为您的外部存储库创建一个单独的 AR,我认为您的大部分问题都会消失。

【讨论】:

  • 但在我的情况下,外部存储库是一个实体而不是 AR。
  • 我的意思是你可能错了,它不是一个实体,它是一个单独的 AR。你有一个 AR(项目),它有一个实体(ExternalRepo),它包含属性(externalRepoId、externalToken、externalRepoType?)你还有一个 AR(ExternalRepository),它包含你没有的外部存储库中的所有位控制,包括协作者等。这样,您可以围绕您通过单个数据库调用无法检索的内容绘制边界。当您只是获取项目列表时,您不会加载每个 repo。
  • 这就是您允许模型与数据库结构显着不同的方式。您在这里确实有两个不同的数据库,您正试图将它们合并到一个 AR、NoSQL DB 和远程存储库(GitHub、BitBucket 等)中。这可能是一个错误,因为它们是独立的“事物”,两者都在您的数据表示,以及在“现实生活”中。远程存储库不是项目的“一部分”,它是项目链接到的东西。链接是项目的“一部分”,因此进入其 AR。
猜你喜欢
  • 1970-01-01
  • 2011-09-16
  • 2021-10-31
  • 2023-02-23
  • 1970-01-01
  • 2015-10-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多