State machines for Entities in DDD and Dependency Injection context?

Question

I've been studying Spring State Machine and State design pattern since I have to develop a microservice with Spring Boot and persisted objects with a lot of confused states that need to be cleared up, and I am looking for a clean design solution out of that mess. I checked DDD, State concepts and State Machine seeing which ones to apply

I am not sure about how to implement some concepts, and how to connect them. I would like to understand if:

1. Spring State Machine can work on entities during transitions, or only on a global application state level?
2. To manage multiple entities each in its own state does it have to have be created as a prototype scoped component?
3. Does it integrate easily with the State pattern or should it not be used together?
4. To manage this, I should inject state or state machines into the Entities (feasible, I know, but I do not like the idea of using @Configurable and appropriate AspectJ weaving configuration)? I share someone's impression that it could make it more complex, and maybe I would have to use @Scope("prototype")
5. Instead if it is possibile to have Domain Services delegate State Machines per entity basis (so another Domain Service) for single entities to change state? Or this is anemic domain antipattern, but if so, how well do State Machine integrates with DDD?
6. Is there any example on how Spring State Machine would allow me to do what I want to do, how lightweight it is, and how slow and memory consuming that would be?

I got that: - DDD wants Domain Objects that have more functionality that simple Data Objects like in this quite complete but a little dated article on DDD - State pattern should encapsulate how the Context element should behave in that particular case - The State Machine is about encapsulating the management of the passage between one State and another - Should they work together, the State should not dictate which is the next State on a specific command, but generate an Event for the State machine and the State machine would choose (or block if there are Guards that fail) the new State - Somehow the new State would have to be set in the Context by the State Machine

Usually the Context object should delegate directly to the State object. But since the State machine dictates the change in the State of the object, should't in this case the Context delegate to a sort of Proxy State? Should be a/the State Machine be injected into the Entity or the Proxy?

Any thoughts, suggestions, even partial answers on some of these questions would be really appreciated.

BTW I just

Answer 1

DDD is all about protecting the business logic and make sure that it's not affected, or coupled, with infrastructure. When you look at an entity, you should directly understand what it's capable of and which part of the domain that it takes care of.

To me, state machines is not part of the domain. They are a facilitator and part of the application layer which controls what should happen in the domain. Then again, it's really hard to answer on an abstract level since DDD is all about modeling on a very "real" level.

If you could explain with a simple example what you are trying to accomplish it would also make it easier to write a more specific answer.