Domain driven design 如何在DDD中建立瞬态模型？

我的第一个领域驱动设计项目刚刚起步。该项目的域模型涉及一个有界上下文，该上下文处理三维场景中移动几何体的碰撞检测

业务逻辑的核心部分是冲突检测算法，也称为CollisionDetector。算法必须配置一些影响其行为和性能的参数。所以它有一些附加的状态，让我首先把它看作一个实体，或者更确切地说是一个集合。请注意，不需要将该实体持久化到DB—它的所有参数值都是瞬态的。还要注意，域中只存在一个CollisionDetector实例，因此实现一个内存中的存储库来访问单个聚合对我来说似乎有点过头了

总的来说，我们有一个具有单态性质的有状态的瞬态实体

所以我的问题是：虽然DDD中的“普通”聚合应该始终通过存储库访问，但我应该如何处理这样一个独特的实体实例

• 在这里使用（邪恶的）单例模式是明智的吗
• 我是否应该向我的国际奥委会注册该实体
• 我是否应该实现一个内存中的存储库来保存单个实例
• 将其建模为一个实体是否合理？（它不需要标识，因为它是唯一的。）
• 我应该重构使其成为（有状态的！）域服务吗
• 对于域模型来说，有几种这种类型的聚合可能是一种设计味道吗
• 我听说过传奇故事。他们能解决我的问题吗

如果你需要更多的背景来帮助我解决这个问题，请现在告诉我

请原谅我的英语不好。我不是以英语为母语的人

编辑：

我觉得我应该给出一些关于

CollisionDetector

类及其附加状态的详细信息

也许称之为短暂是误导。我的意图是指出，

CollisionDetector

永远不会持久化到存储中。它的整个生命都在活动记忆中度过。创建、修改和删除都是其生命周期的一部分，而持久性则不是

CollisionDetector

的另一个重要特性是我所说的它的单例性质，这意味着

CollisionDetector

只实例化一次（但不一定使用GoF单例模式）。我不确定标识的概念是否适用于单例实例（至少不需要标识，因为只有一个），这是阻止我将

CollisionDetector

作为实体/聚合的唯一原因

因此，让我解释一下@plalx、@guillaume31和@arootbeer所要求的

碰撞检测器的状态


如前所述，有一组简单的标量参数值用于调整算法，使其更精确或更快。用户可随时调整这些参数以满足其需求
碰撞检测器
跟踪场景中的几何体及其姿势。这是通过域事件实现的：当其中一个几何体改变其姿势时，事件处理程序将自动触发碰撞测试。同样地，
碰撞检测器
也通过域事件发布新检测到的碰撞。请注意，并非所有几何体都被视为碰撞候选，用户可能会将其中一些几何体从测试中排除。因此，
CollisionDetector
持有几何体ID的黑名单（其状态的一部分）
为了实时检测碰撞，该算法需要在
碰撞检测器
的单独初始化例程中进行预处理。无论何时在场景中添加或删除几何体，预处理都会变得过时，需要刷新。
碰撞检测器知道这一点，即它知道是否需要重新初始化


希望这有帮助

重新思考我的问题，我必须承认这仅仅是学术性的。一个实用的解决方案可能是将
CollisionDetector
作为一个聚合，并将其注册到IoC容器中。你觉得怎么样

算法必须配置有一些影响其行为和性能的参数。因此，它附带了一些状态，使我首先将其视为一个实体，或者更确切地说是一个集合。（强调矿山）

<>我不认为<代码> CollisionDetector < /代码>的配置是它的状态。它只是一种配置，一旦实例化了
碰撞检测器
，就无法更改，因此它比通常在实体中找到的可变状态简单得多

因此，我清楚地考虑了<代码> CollisionDetector <代码>域服务。这意味着您应按以下方式处理：

在IoC中注册
碰撞检测器
服务。
碰撞检测器
的配置可能被认为是域逻辑，因此在
碰撞检测器工厂
中实例化
碰撞检测器
是有意义的。如果您采用这种方法，请在IoC中注册工厂。在任何情况下，请确保
碰撞检测器的客户端不必知道其配置

顺便说一句，在与IoC合作时不要使用单例（即GoF单例模式）。您可以始终将服务注册为单实例，这与单实例模式具有相同的效果，但可以避免其问题。
这听起来像是一项服务。听起来你所谓的“状态”实际上是一组运行时不变的数据；是这样吗？碰撞检测器将处于何种状态