dddshelf / cqrs-by-example-book-issues Goto Github PK

Code examples in the book are great, it would be great to have the code in GitHub.
The mentioned Cheeper code example is not found.

In the example PostCheepCommand, you use a private constructor, in SignUpCommand a public constructor, later a named constructor.
I know the reader should know the difference and when to use it, but is confusing to follow the examples this way.
I think should explain the benefits and tradeoff of fromArray, because in the example is contrary to the phrase in the same chapter "It will also add type safety and IDE assistance, too."

Filling from array is not type safety and the IDE can not help.

1. Preface (ii)

2. Acknowledgements

3. A Journey Towards CQRS (page 7)

Or by using the Factory Method pattern:

(new SignUpCliInputFactory($input)->build();

Must be:

(new SignUpCliInputFactory($input))->build();

Hi @carlosbuenosvinos

I think there is an incorrect reference to an example implementation in the The Command Side section of the Anatomy of CQRS chapter. The example implementation has only one named constructor:

...whereas two different named constructors are being referenced in the following paragraphs:

Thanks!

In the CommandHandler chapter, the UpdateCheepMessageCommandHandler do not publish any event.
Is ok?

The link (https://github.com/cqrs-by-example/cheeper) for code example pointed in book does not exists.

"The DDD recommendation is to implement each Bounded Context as a separate application that
will interact with the others via API calls or a messaging system."
Not sure about this recommendation. I can't remember it.

If we change the ProjectionHandler, it may leave "corrupted" data, as the logic of storing information has change.
Reading old data may crash, as the new ReadModel expect other information.
Updating all the readmodels may not be possible in large tables.
What are the options?
I normally use a "version" attribute, that helps me identify this cases, and I recalculate the projection on realtime, so the first users has some performance impact. (should consider in these case projection stampede)

In the example of Repository at the begining of the book:
interface CheepRepository
{
public function add(Cheep $cheep): void;

I think is better to call it store or persist, as later in the update example you call add( ), what is confusing.

Last paragraph of Other CQRS Components section, just before of Two Sides Of The Same Coin section, affected is duplicated.

It says:
Behind the scenes, the Domain Events, triggered by Command Handlers and **affected** Entities **affected**, will be handled by one or multiple Projectors or Process Managers that will generate the read models optimized for the Query Side. Query requests will simply go and fetch the data ready to be presented to customers.

In the text The DomainModel will contain the Domain concepts such as the Author and Cheep Aggregates or the AuthorRepository and CheepRepository Repositories."

I think is Repositories Interfaces.