This project is read-only.

Conditional State Transitions

Nov 13, 2008 at 2:43 PM
I've just been looking at your project and have a question.

I think we'd be looking to use a workflow framework/DSL to manage high level workflow, entities (DDD aggregates really) would then handle their own workflows (probably just using the state pattern but who knows). At that level you want to be able to say:

state @InTransit:
 when @OrderReceived  and Order.CanTransitionToComplete and Customer.HasPassedCreditCheck >> @OrderComplete

What I'm trying to show that you want to be able to build on top of the domain here, only allowing transitions if the entities (aggregates) involved are happy to proceed. I wouldn't mind mapping from this DSL to the domain and so wondered if you'd considered this style?


Nov 13, 2008 at 3:38 PM
There is a lot of value doing a conditional state change involving the entities rather than external triggers only. Without this, the logic has to be outside of the workflow. The syntax could include boolean operators and supporting basic return types.

state @InTransit:
 when @OrderReceived  and Order.OrderQuantity < Item.StockQuantity >> @OrderComplete
Nov 13, 2008 at 6:25 PM
I agree completely. I haven't gone as far as considering a syntax yet, but I have determined that I will need to include an expression evaluator in the state machine to handle this kind of thing. Simple, dumb state transitions are not enough, as you say. The syntax can be a tricky thing with a Boo DSL though, you can't always get just what you want. My preference would be to move to a regular parser and then the syntax can be whatever makes the most sense. 

Anyway, I'd love to see something like this evolve. It needs some thought, but it is necessary.
Aug 19, 2010 at 8:36 PM
Any solution to this case yet? It would make things a lot easier
Aug 19, 2010 at 10:58 PM
I've more or less moved my attention to Ruby development now. Aalthough we still use SSM in production in our .NET products, we aren't evolving it, and in fact we're in the process of porting our SSM state machines into Ruby. I would, however, be happy to apply a patch. Alternatively, with IronRuby being more or less ready for prime time, you might consider combining IronRuby with a Ruby state machine library such as AASM, state_machine or workflow (see github) to gain the flexible, DSL based syntax characteristic of Ruby and the deep .NET integration of IronRuby.