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

Goggin

I don't know about Spring State Machine, but regarding #5, in "object oriented" DDD a domain object encapsulates both the state and the transition rules. Obviously, functional implementations of DDD don't have that, they are separated. – Crumpler

Yes @guillayne31, but the Domain Object could use the State pattern and so have a State object to which delegate some operations, so by switching State the operations allowed and their implementation change. Should I assume that the current State cannot the transition rules for itself, because he needs access to its Context ? – Goggin

As I understand it, the State object in a State pattern always has a reference to the Context. As long as that Context doesn't capture things that are outside the domain entity, you can safely use a State pattern internally in an entity if you really need to. It will still behave as a normal domain object for the outside world. – Crumpler

+1 @Crumpler as in DDD your entity is the state machine, it has methods to do state transitions (they can be rejected, business exceptions), its clients should know nothing on how it is implemented internally. Then I see Spring State Machine as a way to do the internal implementation of the entity, an ugly way of doing it 😄. Almost joking, I never used it, I'm curious to know if there is some specific reason to use it, as it seems to me more complicated than other solutions. – Kaiserslautern

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.

Catholicize