cqrs - Rebuild queries from domain events by multiple aggregates -

i'm using ddd/cqrs/es approach , have questions modeling aggregate(s) , queries. example consider following scenario:

a user can create workitem, change title , associate other users it. workitem has participants (associated users) , participant can add actions workitem. participants can execute actions.

let's assume users created , need userids.

i have following workitem commands:

• createworkitem
• changetitle
• addparticipant
• addaction
• executeaction

these commands must idempotent, cant add twice same user or action.

and following query:

• workitemdetails (all info work item)

queries updated handlers handle domain events raised workitem aggregate(s) (after they're persisted in eventstore). these events contain workitemid. able rebuild queries on fly, if needed, loading relevant events , processing them in sequence. because users won't access workitems created 1 year ago, don't need have these queries processed. when fetch query doesn't exist, rebuild , store in key/value store ttl.

domain events have aggregateid (used event streamid , shard key) , sequenceid (used eventid within event stream).

so first attempt create large aggregate called workitem had collection of participants , collection of actions. participant , actions entities live within workitem. participant references userid , action references participantid. can have more information, it's not relevant exercise. solution large workitem aggregate can ensure commands idempotent because can validate don't add duplicate participants or actions, , if want rebuild workitemdetails query, load/process events given workitemid.

this works fine because since have 1 aggregate, workitemid can aggregateid, when rebuild query load events given workitemid. however, solution has performance issues of large aggregate (why load participants , actions process changetitle command?).

so next attempt have different aggregates, same workitemid property workitem aggregate has aggregateid. fixes performance issues, can update query because events contain workitemid problem can't rebuild scratch because don't know aggregateids other aggregates, can't load event streams , process them. have workitemid property that's not real aggregateid. can't guarantee process events sequentially, because each aggregate have own event stream, i'm not sure if that's real problem.

another solution can think of have dedicated event stream consolidate workitem events raised multiple aggregates. have event handlers append events fired participant , actions event stream id "{workitemid}:allevents". used rebuild workitemdetails query. sounds hack.. i'm creating "aggregate" has no business operations.

what other solutions have? uncommon rebuild queries on fly? can done when events multiple aggregates (multiple event streams) used build same query? i've searched scenario , haven't found useful. feel i'm missing should obvious, haven't figured what.

any on appreciated.

thanks

i don't think should design aggregates querying concerns in mind. read side here that.

on domain side, focus on consistency concerns (how small can aggregate , domain still remain consistent in single transaction), concurrency (how big can , not suffer concurrent access problems / race conditions ?) , performance (would load thousands of objects in memory perform simple command ? -- asking).

i don't see wrong on-demand read models. it's same reading live stream, except re-create stream when need it. however, might quite lot of work not extraordinary gain, because of time, entities queried after modified. if on-demand becomes "basically every time entity changes", might subscribe live changes. "old" views, definition of "old" not modified more, don't need recalculated anyways, regardless of if have on-demand or continuous system.

if go multiple small aggregates route , read model needs information several sources update itself, have couple of options :

• enrich emitted events additional data

• read multiple event streams , consolidate data build read model. no magic here, read side needs know aggregates involved in particular projection. query other read models if know up-to-date , give data need.

see cqrs events not contain details needed updating read model