gpt4 book ai didi

c# - 防止外部对象调用聚合内实体的方法

转载 作者:行者123 更新时间:2023-12-05 05:13:38 25 4
gpt4 key购买 nike

根据 DDD 原则,外部对象应该只调用聚合根上的方法,而不是聚合中的其他实体,对吗?

对于嵌套实体,例如:SeatingPlan -> Sections -> Rows -> Seats

SeatingPlan 是聚合根,而 sections、rows 和 seats 是在其父实体之外没有意义的实体。


假设我想在座位计划中添加座位。

我会创建 SeatingPlan.AddSeat(sectionId, rowId, seatNo) 以防止外部对象调用 SeatingPlan.Sections[x].Rows[y].Seat[s] .Add,这是不好的,对吧?

但是,SeatingPlan 的 AddSeat 方法必须将座位创建委托(delegate)给行对象,因为座位是行的组合,行拥有座位。所以它必须调用 Sections[x].Rows[y].AddSeat(seatNo)


现在我的问题是如何防止外部对象调用Row.AddSeat 方法,同时允许聚合根调用它?

内部可见性太大,甚至命名空间可见性(假设它甚至存在于 c# 中)也太大了。我需要总体可见性。

我考虑过将类 Row 嵌套在 SeatingPlan 类中,并将 Row.AddSeat 方法设为私有(private)。 但这是一个好的做法吗?因为类必须是公开的,我记得读过一些关于它的文章,说我们应该避免公开嵌套类。

最佳答案

冲突领域模型角色:命令与查询

我怀疑您允许对聚合根进行外部深度导航的原因是为了查询需求,而这正是导致问题的原因。如果您可以避免在根之外暴露实体,那么这个问题就会消失。您一定不要忘记领域模型的主要作用是在保护不变量的同时处理命令;不满足查询需求。

无法同时针对命令和查询优化单个模型。当模型开始让您无法胜任这两个角色之一时,可能是时候将它们分开了。那叫Command Query Responsibility Segregation (CQRS) .您将完全绕过域模型进行查询并直接进入数据库,之后您可以摆脱聚合根中的大多数状态公开成员。

CQRS 吓到我了......

如果您不想走那条路,那么您将不得不忍受将单个模型拉伸(stretch)到不同方向的痛苦。你可以做的一件事来缓解你描述的问题是使用只读接口(interface),例如 IRowView 不公开任何变异方法。或者,您也可以返回描述子实体状态的值对象,例如 RowDescriptorRowState。然而,您将开始意识到,您将开始被迫发明通用语言中不存在的新概念,只是为了解决技术问题(例如,保留封装)。

当心大聚合根

Stadium AR 作为一致性边界似乎非常大。这通常是一个很好的指标,表明边界可能是错误的。您不应该尝试对现实世界建模:仅仅因为体育场包含有行等的部分,在现实世界中并不意味着您的模型应该以这种方式组成。

此外,不要依赖“A 不能存在或没有 B 就没有意义”的规则来建模聚合。大多数时候弊大于利。

因为这不是问题的核心,所以我会让您阅读这篇优秀的 Vaughn Vernon 文章,Effective Aggregate Design .

关于c# - 防止外部对象调用聚合内实体的方法,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/53413709/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com