I am learning Commanded and CQRS in general with a small pet project that is essentially yet another wrapper over a ChatGPT conversation with the prompts/buttons specific to the use case.

I have created a Conversation aggregate and pretty significant part of events is going to be something like ConversationStepAdded.

**Read model**
On the read side in one of the read models I’d want to get a nicely denormalized conversation structure (a nice feature of CQRS!), something like:

- conversation_id
- conversation_title
- some_other_metadata
- a_list_of_conversation_steps
  - conv_step_type // e.g. user or assistant related
  - conv_step_text
  - some_more_step_related_data

Ideally this whole structure will be an Ecto schema with a_list_of_conversation_steps being an embedded_schema (via embeds_many) that is probably going to be mapped to Postgres JSONB field.

**Problem: how to update a_list_of_conversation_steps from a single step event?**
Looking at how commanded projectors work (and CQRS in general?) projection is to be build one event at a time without seeing an aggregate.

Then how would I update a_list_of_conversation_steps when ConversationStepAdded arrives? Since I am learning, I will highly appreciate not only answer to this particular question, but general guidance as well.

• Should I make ConversationStepAdded event carry not just the step being added, but whole list of steps accumulated by now to rewrite whole a_list_of_conversation_steps field via SQL UPDATE?
• Should I go deeper SQL/Ecto and create a complex Ecto.Multi changeset to append a to a_list_of_conversation_steps’es embedded schema and then Ecto will somehow map it to proper SQL (I guess somewhere on the way I will still need to learn which exactly SQL can append to JSONB field)?
  • I guess it could work in this particular case, but not so nicely e.g. if a_list_of_conversation_steps would be just a long string without explicit embedded_schema
• Or is it possible (and recommended?) to have some elixir code there to read the current projection, operate on it in Elixir level (well, still via changeset I suppose) and UPDATE it back to database?
• Or something very different? Maybe the whole approach is wrong and there is a way for this problem not to exist in the first place?

What would you do in such a situation?