我目前深入研究了DDD,需要一点启发。
我有两个实体
TempleTempleVariantTemple (耳机)包含基本信息(名称、描述、.)并有n个变体,具有技术描述(CAD-绘图,尺寸,.)
我的第一印象是:Temple和TempleVariant形成了一个集合--它们属于一起,:它们似乎紧密耦合在一起。
Temple,那么所有的TempleVariant都应该被删除,也应该删除。TempleVariant的没有 Temple就不能存在(至少没有意义)但后来我读到,在之外没有,聚合根目录是,允许引用内的实体,另一个聚合。但实际上,Temple 不是是由外部实体引用的,而是由TempleVariants.引用的。
这是否意味着,在(DDD)现实中,Temple和TempleVariant是不同的聚合物,似乎只是一个聚合体?
但是,如果我删除Temple呢?正如我所说的,TempleVariants也必须删除。但这将违反“一个聚合-更改-一个事务”(或称为:)的规则,因为我的“感觉”是,我必须在一个事务中删除它们.
所以我的问题是:
Lg
瓦拉帕
发布于 2013-04-15 09:20:14
域模型中的每个类都应该映射您从领域专家那里学到的无处不在的语言。这个领域看上去很有趣,顺便说一句。
对我来说,有两条路可以解决你的担忧。
您应该记住,聚合是确保业务不变的必要条件。也就是说:他们接收改变状态的命令,他们有责任避免无效的操作(通过适当的例外情况)。他们往往是实体,因为他们拥有身份。
TempleVariant**s作为值对象**
如果(而且只有当) TempleVariant的实例需要处理业务规则时,它们应该是聚合的一部分。也就是说,Temple包含它们。
但是,它们应该是不可变的对象:只有Temple才能接收更改其状态的命令(总是作为一个整体)。
在这种情况下,当您删除一个寺庙,所有连接的TempleVariants消失。不过,在我开发的大多数DDD应用程序中,没有实体被删除:它们只是存档。但我已经习惯了金融应用和领域,也许在你的领域删除寺庙是正确的做法。
TempleVariant**s作为DTO**
如果Temple中没有命令需要任何TempleVariant来确保业务规则,那么信函可能只是有用的描述性数据,可以通过映射DB模式的适当DTO来处理。在这种情况下,我将定义一个基础设施服务,它返回指定Temple的所有变体。
在本例中,您可以在DTO中公开相关Temple的Temple,但这不是必需的。
关于聚合设计的进一步信息,我强烈建议您阅读弗农关于集合体设计的文章。
发布于 2013-04-15 14:02:57
违反的规则和MikeSW关于“现实世界”中的行为的问题让我重新思考了我的方法。在与领域专家交谈后,我意识到我的方法与域不匹配,因此违反了ddd。我现在正在重新设计我的模型。
@问题:如果我把TempleVariant放在Temple模型中,我就会使用TempleVariant方法来引用一个变体(如MattDavey所建议的)。,但是设计中更重要的错误仍然存在.
如果基本设计是正确的,我将使两个单独的聚合根。从我的角度来看,这是可行的,但是,,它会让覆盖一个设计错误(至少在我的例子中是这样)。
通常是,我认为,如果ddd规则被违反了,最好是后退一步,检查的实际业务,检查惠特您拥有的东西是否与您的域名匹配。
谢谢你的帮助!
https://stackoverflow.com/questions/16010405
复制相似问题