CODEWITHSUNDEEP
symfonydesign-patternsworkflowstate-machine
Rufinus
Rufinus

Reputation: 30763

StateMachine over multiple Entities

I have 4 entity types, each has its own StateMachine. There are transitions which also should invoke transitions on one or more different entity types.

I can solve this via the event system (either in entered or transition events) but this just doesn't look right. And it's hard to follow all cases and ensure that all dependencies are taken care of.

What would be a design-pattern for such a use-case? I need a way to connect independent StateMachines together.

Upvotes: 1

Views: 620

Answers (2)

Rufinus
Rufinus

Reputation: 30763

As much as I appreciated @StepUp's answer, it doesn't quite fit my needs. The Applicaiton already uses events quite a bit (or read messages). CQRS would be a major rewrite and as the auditing of the state changes is not needed I don't see a big enough benefit in it. Saga seems interesting but as this is not a microservice context is would be to much.

After thinking about it for quite some time I come to the realisation that Observer would just inverse the responsibility to the other side. I need something central.

The solution will be a Mediator Pattern. The Mediator (and only the mediator) will know about which workflow has dependencies on other workflows. The Workflow itself doesn't need to know this. As the StateMachine already fires events, I can use them to call the mediator and the Mediators will know what to do.

Upvotes: 0

StepUp
StepUp

Reputation: 38199

It seems that Observer pattern would be really appropriate for the case where entities are in one project. Otherwise, if there are microservices, then it is possible to apply the following patterns.

It seems that you have entities that can be separated from each other and these entities can be considered as a standalone microservice. If yes, then we can try to apply the following patterns of microservices.

Pattern: Messaging

Use asynchronous messaging for inter-service communication. Services communicating by exchanging messages over messaging channels. There are several different styles of asynchronous communication:

  • Request/response - a service sends a request message to a recipient and expects to receive a reply message promptly
  • Notifications - a sender sends a message a recipient but does not expect a reply. Nor is one sent.
  • Request/asynchronous response - a service sends a request message to a recipient and expects to receive a reply message eventually
  • Publish/subscribe - a service publishes a message to zero or more recipients
  • Publish/asynchronous response - a service publishes a request to one or recipients, some of whom send back a reply

Pattern: Saga

Implement each business transaction that spans multiple services as a saga. A saga is a sequence of local transactions. Each local transaction updates the database and publishes a message or event to trigger the next local transaction in the saga. If a local transaction fails because it violates a business rule then the saga executes a series of compensating transactions that undo the changes that were made by the preceding local transactions.

Pattern: Command Query Responsibility Segregation (CQRS)

Define a view database, which is a read-only replica that is designed to support that query. The application keeps the replica up to data by subscribing to Domain events published by the service that own the data.

Upvotes: 1

Related Questions