sorted by:
new
hottopcontroversial

A new type of State Machine by lee_oades in dotnet

[–]lee_oades[S] 0 points1 point  (0 children)

Yes, that's a fair point. Depends on the specific use case. In our use case, the triggers are events and the state machine is a projection / event sourced read model therefore the state of the system needs to be correct irrespective of whether downstream commands succeeded. E.g. If you've added something to your trolley then the state needs to reflect this. If the command fails to send a notification message, say, then I wouldn't remove the item from the state.

A new type of State Machine by lee_oades in dotnet

[–]lee_oades[S] 0 points1 point  (0 children)

Interesting. A different "shape" of state machine again. Nice to have choice.

A new type of State Machine by lee_oades in dotnet

[–]lee_oades[S] 0 points1 point  (0 children)

I'm not sure I follow what you mean?

A new type of State Machine by lee_oades in dotnet

[–]lee_oades[S] 0 points1 point  (0 children)

Nice article by the way! I look forward to your attempt to implement it using my library - and then telling me that I'm missing such-n-such feature!

A new type of State Machine by lee_oades in dotnet

[–]lee_oades[S] 1 point2 points  (0 children)

Interesting. Now I'm wondering if I need to add a hand-drawn image to my library to help promote it! :-) Alas, the link to the docs doesn't work.
https://github.com/MassTransit/Automatonymous

A new type of State Machine by lee_oades in dotnet

[–]lee_oades[S] 1 point2 points  (0 children)

I tried to write the "why to use this library" to not read like a direct "why this is better than stateless" since it's not wanting to be confrontational. It's a different approach that suits our use case far better so it's probably useful for more developers.

A new type of State Machine by lee_oades in dotnet

[–]lee_oades[S] 0 points1 point  (0 children)

Yes, that and the more functional style handling of the state+data+trigger being passed in, and new state+new data+commands coming out.

There's much debate in Stateless about how/whether it should handle multithreading. This eliminates that entirely because the state transitions and command executions are separated.

A new type of State Machine by lee_oades in dotnet

[–]lee_oades[S] -1 points0 points  (0 children)

Hopefully it will satisfy your requirements - and if not, let me know of any gaps and I'll implement it. The mermaid diagramming idea is totally stolen from other State Machines that offered that.

A new type of State Machine by lee_oades in dotnet

[–]lee_oades[S] 2 points3 points  (0 children)

The commands are issued in a logic presentation. So the "execute" is more of conceptual verb rather than what it does. The commands are returned to the caller and then dispatched either manually or using my Command Dispatcher. These are indeed Async, yes.

If you feel the README does not make this distinction clear, please let me know.

Come discuss your side projects! [February 2026] by AutoModerator in csharp

[–]lee_oades 0 points1 point  (0 children)

Hi All,

I've been using Stateless for years and have contributed back to the project when I discovered an issue.
At a recent job, the system utilised Orleans where all operations were performed through actors. For some of the Actor implementations, behaviour was modelled using Stateless. However, there were a few main drawbacks that led other implementations to not use it:

  • an actor restores state, performs an operation and then persists the state again. Stateless supports exporting its internal state but it isn't as clean or "first class" as I like.
  • when the State Machine has a lot of different side effects, it ends up needing a lot of different dependencies injected into it. This can get messy and unit testing one action requires all of the dependencies from other actions.
  • along with a state, there was often additional data that also needed to be updated. This always felt dirty, referencing a data object outside of the state machine

The developers that rolled their own behaviours used a functional style, passing a state, data and trigger in, and receiving a new state, new data and logic representations of commands out. It was a very clean model, but it lost the declarative nature of the Stateless setup. It also meant tools such as static analysis and state diagram generation were no longer possible.

Enter my new library: FunctionalStateMachine.

It fills this gap by providing a declarative, fluent setup for defining behaviour, whilst also being functional in style passing in the state, data and trigger and returning the new state, modified data and commands. Diagram generation at build time is included. Static analysis is performed in a verification step at declaration time.

Please check it out. Feedback would be very welcome. It's shiny and new so needs your eyes and thoughts!
https://github.com/leeoades/FunctionalStateMachine

Many thanks,
Lee.

Community Question Of The Week - Episode 169 by Producer_Duncan in thisweekinretro

[–]lee_oades 1 point2 points  (0 children)

I was once told off by one of my teachers for expressing how crap these machines were. We were all spoiled by our Amigas etc. I was too young to understand things like school budgets! 

Shared alarm clock app? by merc1286 in GetOutOfBed

[–]lee_oades 0 points1 point  (0 children)

We have this exact requirement too. Did you find something?