Thank you Michael and Udi, this makes things a little clearer.

Assuming that we take the 'domain object contains internal state'-approach, how would this state get into the domain object? The query side contains all the code to fetch state from persistent storage and apply the events, so we could call that when creating a domain object to get the state.

At the same time, something tells me that this is not a good way to work because it mixes the command and query bounded contexts. With the only advantage being that we can call existing code the added complexity is probably not worth the cost.

When firing events from the domain objects I assume that there will be a class that intercepts these events, persists them and routes them to the query repositories for 'processing' to update the query-data?

> Jesper,
>
>
>
> While the query side exposes state, it's not that the command side doesn't
> have its own state.
>
>
>
> So, to this:
>
>
>
> "It does not make sense to actually set the address in the customer object
> because it should not contain the state"
>
>
>
> It actual makes perfect sense (unless you're doing the commands-as-state
> pattern that Greg is talking about).
>
>
>
> -- Udi Dahan