我目前正在确定系统中的实体,值对象和聚合。说已经确定了以下实体:

客户,客户邮件,电子邮件,客户编辑,地址,地址类型

客户 - >电子邮件与许多关系 - 客户 - >地址(带有地址类型)的地方。这些关系由客户添加剂和客户邮件关系对象表示。

最初,我认为这很简单:

实体:客户,客户邮件,customeraddress值对象:电子邮件,地址,地址类型

客户是包含上面所有实体和vo的聚合的总词根。

我遇到的问题(这可能只是我在学习时正在学习聚合的概念时)说,您有一个供应商实体,使用相同的地址和电子邮件值对象反映上述客户汇总。在这种情况下,当客户被删除时,地址和电子邮件不应作为供应商删除,甚至其他客户仍然可能引用他们。我看到了很多文档,这些文档表明何时删除了一个聚合物,总共删除了整个汇总边界内的所有内容。我是否正确地假设这不适用于总体中的值对象(即它们是不变的...如果我们在车辆汇总中有颜色对象绿色...您不会仅仅因为汽车而删除颜色被删除),或者,电子邮件和地址是否应该存在自己的实体(和汇总)作为两个地址,即使它们可能具有相同的属性,也是实际的单独身份(即。一个是供应商地址,另一个是客户地址?)

最后,如果它们确实是有价值的对象,则如何处理应删除应删除的情况(没有供应商或客户参考地址),如果VO仅通过其汇总行为才能采取行动?

干杯,

史蒂夫

有帮助吗?

解决方案

您正在考虑数据库热的域。不建议这样做。

反映上述客户聚合的供应商实体

这表明您缺少域中的概念。这对您的域专家意味着什么?如果确实存在关系,则应明确建模。

您说“客户 - >电子邮件是很多与许多关系的关系”。多个客户共享电子邮件对您的域名有意义吗?如果是的话,您可能会缺少一个概念。检查您的领域专家对这种关系的评价。如果对很多人来说并不多,但是一票比这是一封电子邮件是客户实体“拥有”的价值对象。现在,如果客户拥有电子邮件或地址,则可以在没有任何限制的情况下将其删除(或采取行动)。

DDD最困难的事情之一是,您总是试图在聚合之间共享实体。不。您打败了聚合的孔点 - 一致性边界。取而代之的是,借助您的领域,专家确定了缺失的概念,这些概念将阐明AR之间的边界。

我知道这听起来很抽象(过去我问过这样的问题),但事实是,只有您的域专家才能帮助您更好地建模域。

作为最后的建议-Re(-re x 100)阅读埃里克·埃文斯(Eric Evans)的书通常会有所帮助:)

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top