我正在使用DDD方法重新设计一些代码。该领域是住宿护理，我正在处理的代码是关于为个人居民执行的任务。就UL而言，我必须在这里即兴创作，所有条款最初都是德语，其含义可能会在翻译中丢失。
中央聚合是任务。任务指的是需要为特定居民完成的事情，例如血糖控制。为了简单起见，我们假设每个任务都安排在特定的日期和时间，以便血糖控制可以安排在今天，9点钟。护士将采取血糖值，然后在软件中确认她执行了任务。
然而，血糖测量本身就是一个聚合体，因为护士可以在没有任务的情况下进行测量（例如，如果居民即将晕倒）。此外，如果出现异常情况，护士可以为每个任务写一份简短的报告。当然，该报告与该特定任务有关。和血糖测量一样，护士可以在没有执行任何任务的情况下撰写报告。
任务实际上可以要求报告，就像护士无法在没有报告的情况下确认任务一样。与BloodSugarMeasurement相同，例如，任务可能是“服务2片面包”并且需要BloodSugarMeasurement。
事实上，为了确认某项特定任务，我可能需要将一些内容翻译为“附加内容”。
在我的方法中，Task有一个Addition集合（例如BloodSugarMeasurement），你必须在确认任务之前提交这些Additions，伪代码：
task.Submit(new BloodSugarMeasurement(...));
task.Confirm(name, dateTime);
Task.Confirm显然会检查是否所有Addition都已提交。
现在从我在各种论坛中学到的内容来看，不建议实际引用其他聚合根但只包含其ID。
事实上，将包括所有可能的Additions的Task聚合映射到数据库已经开始变得非常混乱，所以我想知道，我是否还在正确的轨道上或是否有更好的方法来模拟任务聚合？