答案 0 :(得分：5)
我会以CQRS方式处理这种情况，即使用事件存储并在架构级别将读取与写入完全分开。但是我认为你提到的问题更加符合普通的DDD方式 - 所以我会在这个背景下回答它。
你需要完全摆脱“数据驱动”的思考。从主要工作流程开始。第一次和第三次使用基本上只是获取操作。我将首先关注聚合根状态发生变化的用例。因此，使用案例2，即“执行评估”将是一个很好的起点。
正如您正确指出的那样，聚合根将是评估。可以创建“PerformAssessmentService”类（相当于域服务），此处将存在执行评估工作流。此工作流程将完全处于测试状态，其中所有依赖项（例如存储库）都被简单地删除。
您可能最终编写整个执行评估工作流程而没有任何具体的数据库/ UI实现等。所有业务逻辑都在此域服务中编排，并且所有逻辑都存在于您的评估实体和其他关联实体中。
转到下一个用例 - 也许用例4 - 修改评估（再次如上所述）
在您的实施中尽可能晚地保留诸如存储库/数据库，UI等外围设备。重要的是首先锁定您域中的所有业务逻辑 - 然后从域中驱动您的外围设备问题 - 它更便宜/更高效（根据我的经验）
请注意，没有正确的方法可以做到这一点，这只是我将如何处理上述项目的概要。关键在于域名实际上是实施所有内容的驱动因素......
答案 1 :(得分：0)
我将从一个使用内存存储库的快速而肮脏的原型开始。如果你走的是正确的道路，你会得到一个更好的主意。