【问题标题】:how to model one to many relationship in domain driven design如何在领域驱动设计中建模一对多关系
【发布时间】:2016-08-08 10:50:59
【问题描述】:

我正在使用领域驱动设计并使用 nhibernate 作为 ORM

我有一个名为 Certificate 的实体和一个名为 Condition 的实体,以及一个用于保存这两个实体之间的一对多关系的中间表。

一个条件可以有多个证书

由于条件和证书是单独的聚合根,并且基于域驱动的规则,我不能在另一个中保存聚合,并且只能将 agregateId 放在其中。因此将下面的代码放在条件聚合中不可能是真的

 private List<Certificate> _certificateList; 
.
.
.
 public IReadOnlyCollection<Certificate> CertificateList { get { return _certificateList.AsReadOnly(); } }

下面的代码似乎也不正确

 private List<CertificateId> _certificateIdList; 
.
.
.
 public IReadOnlyCollection<CertificateId> CertificateIdList { get { return _certificateIdList.AsReadOnly(); } }

你能帮我模拟这种关系吗?

谢谢

【问题讨论】:

  • 感谢您的回复,但我无法理解您的意思?
  • 这是两个不同且独立的集合,但我不知道如何为关系建模
  • 抱歉给您带来了困扰,本来想写个澄清评论,没来得及写完,不小心发了。我会在今晚 (CEST) 抽出时间再回来查看。
  • 感谢您的回复

标签: nhibernate domain-driven-design one-to-many


【解决方案1】:

这取决于您的业务规则,但如果没有跨越相同条件的所有证书的规则,那么您可以在 Certificate 中引用 conditionId 并依靠数据库查询来获取关联。

【讨论】:

  • 同意这个解决方案。对于 OP,您这样做的原因是为了保留聚合之间的事务边界。虽然聚合体必须保持隔离的纯度和持久性,但这并不意味着它们相信它们是系统中唯一的聚合体。实体标识符经常被混淆为仅仅是一种持久性机制,而事实并非如此。无论过渡或交易状态如何,所有实体都应该是可识别的。
  • plalx 和 joseph,感谢您的回复,但我需要拥有特定条件的所有证书,以及证书的条件。因此,显然我需要将条件 ID 放入证书中,并将证书 ID 列表放入条件聚合中。这是聚合之间的真正设计吗?
  • 只向 CertificateRepository 发出 GetCertificateListForCondition 之类的查询没有问题。当没有不变量需要保护时,IMO 不需要条件中的集合。
  • > 但我需要拥有特定条件的所有证书,以及证书的条件为什么需要它们?你是否试图在你的聚合中强制执行任何不变量?你将如何使用它们?拥有这些 Id(对其他聚合的引用)是可以的,除非您想在之后加载所有这些 Id。这可能会导致性能下降。
猜你喜欢
  • 2015-05-17
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2010-10-15
  • 1970-01-01
  • 2012-05-28
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多