Is this really CQRS? No separation between Command and Query domains. about nest-cqrs-example HOT 5 OPEN

@johncmunson do you have a reference for a better example like this repo, other than the link you provided in your comment. I am interested in learning the correct pattern.

from nest-cqrs-example.

I believe, instead having the previous query handler signature, it should be better to have something like:

export class GetHeroesHandler implements IQueryHandler<GetHeroesQuery, GetHeroesResponse>

Where GetHeroesResponse configures another domain to be proper returned on handler.

from nest-cqrs-example.

+1

from nest-cqrs-example.

There seem to be 2 conceptual differences between this package and what is generally recognized as the CQRS pattern. Unfortunately these differences can't be changed in a non-backwards compatible way. In the current implementation, ICommand is completely separate and parallel to IEvent but it should probably extend IEvent instead (at least, I think this is the fastest and easiest way of addressing this issue). The other issue is that Sagas are implemented as projections; not sagas -- they should be listening to the event stream; not the command stream. Canonically, sagas are used to coordinate between multiple aggregate roots. Projections are derived constructs from events.

In DDD the difference between commands and events is the intent of the calling system. An event is a fact, a command is a request to change the state of the aggregate. In the code, the execute method for EventHandlers are correctly defined as pure functions. This means that aggregate state is therefore defined as chained calls to event handlers -- h(h(h({state}))). However, that's only true if commands don't also change aggregate root state. Replaying only the events will have the effect of recreating aggregate state; allowing you to deal with system updates gracefully. State changes therefore get split into 2 parts: the command (the intent -- CreateOrder) and the resulting factual event (OrderCreated). If you were to replay the CreateOrder command it would have the effect of creating a new corresponding OrderCreated event. However, if you only replay the event, the system will gracefully recover. The sample project is so trivial that it side-steps one of the most common issues facing CQRS and event streamed applications -- aggregate mutations are almost always a 2-step process.

I see a lot of code in this package to support management of the AggregateRoot (a lot of autocommit and replay code is there), but it can never work because of the command / event issue. Projections have a similar problem -- they should be created from the event stream; not the command side. That's not to say that listening to commands isn't useful, the current implementation is superb for decoupling validations and provide a convenient place to persist commands. However, the name is different to what is generally understood with this pattern.

from nest-cqrs-example.