Exploring a declarative, spec‑first approach to decisions and projections in CQRS‑ES

Axon Framework
, , , ,
1

Hi everyone — we’ve started opening up a spec we’ve been working on and wanted to involve this community early.

The focus is DeQL (Decision Query Language): a declarative way to model CQRS / Event‑Sourced systems where decisions and projections are both treated as first‑class concepts.

The motivation came from a recurring pain we kept seeing in real systems:

most approaches simplify either the command/decision side or the projection/read side —

but rarely both. Complexity ends up getting relocated rather than removed.

What we’re proposing at the spec level:

– decisions expressed as guarded rules, not imperative handlers

– projections declared as disposable/replayable artifacts

– ability to INSPECT decisions and projections against data, without side effects

Right now this is intentionally **spec‑first**.

We’d like to evolve it with practitioners rather than locking ourselves into one “right” implementation.

We’re particularly interested in discussion around:

– trade‑offs this model introduces

– where it clashes with patterns you’ve found effective

– ideas for runtimes / execution models that would (or wouldn’t) fit

– how this compares to code‑first CQRS approaches you’ve worked with

Docs + examples are here for context:

Not a framework pitch — genuinely looking to learn from the group and shape the spec with real‑world input.

1 Like
2

Hey @Kiran_Kumar, I spotted this exact same post on the DDD Discord server and was intrigued! I am not doing it justice for sure, but after doing a quick pass, it reminded me just so slightly about the Development Agent we’ve integrated into Axoniq Platform. However, the spec could be the output of the agent, followed by (Framework) integration. Again, likely not doing it justice, just wanted to share my first gut feeling here.

Apart from that, I have question: how are you looking to get feedback on this? Do you have some forum, mail list, Slack/Discord/etc to give feedback on?

Ow, and PS:

Not a framework pitch — genuinely looking to learn from the group and shape the spec with real‑world input.

It would be perfectly fine if it was a framework pitch as well. Nothing wrong with having more players on the field if you ask me. It only shows the maturity of this area.

1 Like