相关疑难解决方法(0)

我需要帮助找到我的聚合根和边界.

我有3个实体:Plan,PlannedRole和PlannedTraining.每个计划都可以包含许多PlannedRoles和PlannedTraining.

解决方案1:起初我认为Plan是聚合根,因为PlannedRole和PlannedTraining在计划的上下文中没有意义.他们总是在计划之内.此外,我们有一个业务规则,即每个计划最多可以有3个PlannedRoles和5个PlannedTraining.所以我认为通过提名计划作为聚合根,我可以强制执行这个不变量.

但是,我们有一个搜索页面,用户可在其中搜索计划.结果显示了计划本身的一些属性(而不是PlannedRoles或PlannedTrainings).我想如果我必须加载整个聚合,它会有很多开销.有近3000个计划,每个计划可能有几个孩子.将所有这些对象加载到一起然后忽略搜索页面中的PlannedRoles和PlannedTraining对我来说没有意义.

解决方案2:我刚刚意识到用户还需要2个搜索页面,他们可以搜索计划角色或计划培训.这让我意识到他们正试图独立地访问这些对象并"脱离"Plan的背景.所以我认为我的初始设计错了,这就是我想出这个解决方案的方法.所以,我认为这里有3个聚合,每个实体有1个聚合.

这种方法使我能够独立搜索每个实体,并解决了解决方案1中的性能问题.但是,使用这种方法我不能强制执行前面提到的不变量.

还有另一个不变量,即只有在具有特定状态时才能更改计划.因此,我不能将任何PlannedRoles或PlannedTrainings添加到不处于该状态的计划中.同样,我不能用第二种方法强制执行这种不变量.

任何建议将不胜感激.

干杯,莫什

让我们考虑典型的Order和OrderItem示例.假设OrderItem是Order Aggregate的一部分,它只能通过Order添加.所以,新添加OrderItem的一个订单,我们必须通过信息库加载整个集合,添加一个新项目的订单对象,并再次坚持整个集合.

这似乎有很多开销.如果我们的订单有10个OrderItems怎么办？这样,只是为了添加一个新的OrderItem,我们不仅需要读取10个OrderItems,而且我们还应该重新插入所有这10个OrderItems.(这是Jimmy Nillson在他的DDD书中采用的方法.每次他想要坚持一个Aggregate,他清除所有子对象,然后再次重新插入它们.这可能会导致其他问题,因为孩子的ID是由于数据库中的IDENTITY列,每次都会更改.)

我知道有些人可能会建议在Aggregate Root中应用Unit of Work模式,以便跟踪已更改的内容并仅提交这些更改.但这违反了持久性无知(PI)原则,因为持久性逻辑正在泄漏到域模型中.

以前有人想过这件事吗？

MOSH