Regarding similarities to Commanded, CQRS and Functional Event Sourcing - yes, you are spot on. I’ve stayed away from any CQRS language when describing Jido simply because “Agents” as a pattern was still evolving. I found a few edge cases where Agents bend the rules of CQRS & Event Sourcing enough that I didn’t want to add confusion. Your list of differences is a good start, there’s a few others.
The book “Real World Event Sourcing” was a great resource for me and fingerprints from that book are all over Jido. Sensors implement the Event Sourcing “gateway” as well etc.
I did my best to implement solid patterns across Jido in other places as well.
Actions and the lesser known %Instruction form a Command Pattern upon which all of Jido is based. Being very intentional about the architectural boundaries here led to splitting this all out as the jido_action package.
If you squint a bit, Agent State can be termed as a specialized form of an Aggregate. Again, I didn’t pull out the Event Sourcing rules around Aggregates - I decided to optimize more for the developer experience etc.
Am I reading correctly that “state checkpointing” is the durability strategy employed?
Right now, yes. My strategy here hasn’t been super mature yet. The task for the 2.0 release was to stabilize the extension points - which was accomplished via Jido.Storage and Jido.Persist Persistence & Storage — Jido v2.3.2
I envision extra packages for persistence to Redis and Postgres which will help dial this in.
I also really want to nail the clustered durability story as well - I’ve looked at a few solutions to this but don’t have anything concrete yet.
Hope that answers your question - happy to chat more!
