Question

我正在构建一个管理人员信息的系统。我有一个不断增长的聚合根称为Person。它现在有数百个相关的对象，名称，地址，技能，缺席等。我担心的是，AR AR会破坏SRP，并且会随着越来越多的东西（esp集合）被添加到它中而产生性能问题。

我无法看到DDD如何将其分解为更小的对象。以缺席为例。 Person有一组缺勤记录（startdate，enddate，reason）。这些目前通过Person（BookAbsence，ChangeAbsence，CancelAbsence）进行管理。添加缺席时我需要对所有其他缺席进行验证，因此我需要一个可以访问其他缺席的对象来进行此验证。

我在这里遗漏了什么吗？还有其他AR我没有确定？在过去，我会通过“AbsenceManager”服务完成此操作，但希望使用DDD。

我对DDD很新，所以也许我错过了一些东西。

非常感谢....

Answer 1

缺席可以建模为聚合。当您想添加新的缺席时， AbsenceFactory 可用于验证其他缺席。

代码示例：

public class AbsenceFactory {
    private AbsenceRepository absenceRepository;
    public Absence newAbsenceOf(Person person) {
         List<Absence> current = 
              absenceRepository.findAll(person.getIdentifier());
         //validate and return
    }
}

你可以在蓝皮书中找到这种模式（如果我没有弄错的话，请参见6.2工厂）

在其他“修改”案例中，您可以引入规范

public class SomeAbsenceSpecification {
    private AbsenceRepository absenceRepository;

    public SomeAbsenceSpecification(AbsenceRepository absenceRepository) {
        this.absenceRepository=absenceRepository;
    } 

    public boolean isSatisfiedBy(Absence absence) {
          List<Absence> current = 
              absenceRepository.findAll(absence.getPersonIdentifier());
         //validate and return
    }
}

您可以在蓝皮书（第9.2.3节规范）中找到此模式

Answer 2

这确实是使聚合设计变得如此棘手的原因。所有权并不一定意味着汇总。我们需要了解域名才能给出正确答案，因此我们将使用好的Order示例。 Customer没有Order个对象的集合。最简单的规则是考虑删除AR。那些在没有AR的情况下可以有意义的对象可能不属于AR。但是，Customer很可能拥有ActiveOrder个对象的集合。当然会有一个不变的声明，如果客户有活动订单，就无法删除。

需要注意的另一件事是臃肿的有界背景。可以想象，您可能有一个或多个有限的上下文未被识别，导致您的AR做得太多。

因此，如果Absence被删除，您可能仍然对Customer感兴趣。在OrderLine的情况下，如果没有Order则没有意义。所以没有自己的生命周期。

希望有所帮助。

Answer 3

我正在构建一个管理人员信息的系统。

您确定通过SQL编辑/查询RDBMS表的简单CRUD应用程序是不是更便宜的方法？

如果您可以在数据关系和表操作方面表达大部分业务规则，则根本不应使用DDD。

我有一个不断增长的聚合根名为Person。

如果您确实拥有复杂的业务规则，那么不断增长的聚合通常是未定义（或错误定义）context boundaries的合成。

DDD：大聚合根 - 人

3 个答案: