Why not use a “context” plus a unit od work. The aggregate doesnt need the envelope.
public class Context {
public void Enlist(Event e) {
_events.Add(e);
}
public void Set(Command c) {
//remember
}
public void GetEvents() {
return _events.Select( ..... ); build envelopes here if you want
}
public static Context Current //or use DI etc
}
Now in a composite command handler
public void AddContext<T>(T command, Action<T> next) {
Context.Current().Set(command);
next(command);
}
Seems much simpler… 
OK, I’ll try and se what I can do with that. Thanks.
Is this a common solution?
Wouldn’t I have to put a dependency on this context in the Aggregate to use those events?
The repository either gets the events from the context, or from the aggregate. As it is now, repository takes aggregate, extracts the events, saves them, and clears uncommitted events.
OK, I could pass context instead, and clear uncommitted from aggregate after repository.Save(…) returns. But the aggregate is heavily used in the CommonDomain repository.
It seems brittle to keep the same events both in the context and in the aggregate. Now we suddenly have a consistency issue.
I’m failing to see how the context should be used. Is it passed to specialized command handlers from the composite one? When would events be added to it? I’m sure there’s a really nifty way to handle it, I’m just not seeing it.
Context is AKA as UnitOfWork ..
and yes its very common.
You should seriously consider not using that library.
well yeah, I know context is uow, and I wasn’t asking if uow is common, but rather if that way you described it is common for CQRS + ES.
Anyway, it would be really good to know why I should consider not using that library. It’s not that I think I should, I just haven’t seen any comments about it being inferior before. Like many others I’m more of a “ah, I can understand that”-person than a “oh, he says so”-person. 
It’s just the EventStore repository that I’m using btw. I’ve only seen positive things, like this https://groups.google.com/forum/#!searchin/event-store/CommonDomain/event-store/l4jwAiPxe64/idhoT0QSPFYJ mentioned about it before.
well yeah, I know context is uow, and I wasn't asking if uow is common, but
rather if that way you described it is common for CQRS + ES.
yes its common they are the same pattern.
well yeah, I know context is uow, and I wasn't asking if uow is common, but
rather if that way you described it is common for CQRS + ES.
Doing headers by context is hard when using aggregates the way they
work in your example. With a UOW its trivial. Just use the UOW and
your problem goes away.
Anyway, it would be really good to know why I should consider not using that
library. It's not that I think I should, I just haven't seen any comments
about it being inferior before. Like many others I'm more of a "ah, I can
understand that"-person than a "oh, he says so"-person.
Try asking on the neventstore list there has even been talk about
removing it from neventstore.
OK, great, posted a question about it there. Thanks a lot for answering all these questions. Thumbs up
Doing headers by context is hard when using aggregates the way they
work in your example. With a UOW its trivial. Just use the UOW and
your problem goes away.
I think I have it solved, using the “hard” way. I just couldn’t understand how to implement the UOW easily. I know, must seem daft, but I got stuck on the questions above and couldn’t bend my mind right - they’re all wrought around this complex solution of mine now ^^