Nice. Our architecture has had somewhat of a different primitive for years that yields the same outcome. Our application architecture is named The Feature Arc

Nice. Our architecture has had somewhat of a different primitive for years that yields the same outcome. Our application architecture is named The Feature Architecture. A unit of work is feature. A lot of common implementation can be derived from (or compressed into) the name of a feature. They are invoked by Features.invoke(feature_name,...) and seamlessly calls same service, service to service or frontend to backend service or even backend to frontend (with client ID and userid) seamlessly. A command feature by default does durable execution by being a consumer as well as a feature as the machinery ensures all incoming command feature messages are injected into monolog (in house built akin to kafka). So command feature errors are retried by the machinery by default. All Dip operations are idempotent and hence can be retried maximally. Our arcc (The architecture compiler) enforces at compile time that 1) there are zero CQRS violations of query to command invocations 2) zero violations of query to Dip.insert/update/remove (extended CQRS for persistence) 3) all Dip mutate operations are idempotent (arcc --strict), 4) zero alien Dip collection access (a feature leaf and its handlers owns exactly one collection) 5) and a whole myriad of around 10 different architecture rules that usually depend on developer discipline and conventions. One can set a command operation to be not a durable execution by specifying bypass: true for that feature in the registry but those are the outliers. Checkpointing and replay are not mutually exclusive in our architecture as they emerge when a command feature is either a default or one with bypass: true. So durable executions are inherently native and first class for all commands in our Feature Architecture.