jpa - DDD和依赖注入(inject)上下文中实体的状态机？

Question

我一直在学习Spring State Machine和 State design pattern因为我必须使用 Spring Boot 开发一个微服务，并且持久化对象有很多需要清理的困惑状态，我正在寻找一个干净的设计解决方案。我检查了 DDD、状态概念和状态机，看看要应用哪些

我不确定如何实现一些概念，以及如何连接它们。我想了解是否:

Spring State Machine 可以在转换期间对实体工作，还是只能在全局应用程序状态级别上工作？

要管理多个实体，每个实体都处于自己的状态，是否必须将其创建为原型(prototype)范围的组件？

它是否容易与状态模式集成，还是不应该一起使用？

为了管理这个，我应该将状态或状态机注入(inject)到实体中(可行，我知道，但我不喜欢 using @Configurable and appropriate AspectJ weaving configuration 的想法)？我分享someone's impression它可以使它更复杂，也许我不得不使用@Scope("prototype")

相反，如果有可能让域服务在每个实体的基础上委托(delegate)状态机(因此另一个域服务)以供单个实体更改状态？或者这是 anemic domain antipattern ，但如果是这样，状态机与 DDD 的集成效果如何？

有没有关于 Spring State Machine 如何让我做我想做的事情的例子，它有多轻量级，以及它有多慢和消耗内存？

我明白了:
- DDD 希望域对象具有比此 quite complete but a little dated article 中的简单数据对象更多功能的域对象在 DDD 上
- 状态模式应该封装上下文元素在特定情况下的行为方式
- 状态机是关于封装一个状态与另一个状态之间 channel 的管理
- 如果它们一起工作，State 不应该在特定命令上指定哪个是下一个 State，而是为 State machine 生成一个 Event，State machine 将选择(如果有 Guards 失败，则阻止)新 State
- 状态机必须以某种方式在上下文中设置新状态

通常 Context 对象应该直接委托(delegate)给 State 对象。但是由于状态机决定了对象状态的变化，在这种情况下，上下文不应该委托(delegate)给某种代理状态吗？应该将状态机注入(inject)实体还是代理？

非常感谢您对其中一些问题的任何想法、建议，甚至部分答案。

顺便说一句，我只是

Answer 1

DDD 是关于保护业务逻辑并确保它不受基础设施影响或耦合的。当您查看一个实体时，您应该直接了解它的能力以及它负责的领域的哪一部分。
对我来说，状态机不是领域的一部分。它们是促进者，也是应用层的一部分，控制着领域中应该发生的事情。再说一次，在抽象层面上真的很难回答，因为 DDD 都是关于在非常“真实”层面上建模的。
如果您可以用一个简单的示例来解释您要完成的工作，那么它也将使编写更具体的答案变得更加容易。