Hi Oskar, thanks for this series and for showing the thought process involved in evolving the system.
I have a question regarding the composition of the HTTP handlers.
How is the system able to tell apart the // Add Product Item and the // Remove Product Item endpoint? How is it going to know whether you want to call the command AddProductItemToShoppingCart or RemoveProductItemFromShoppingCart?
In the current definition both endpoints are defined as router.post('/clients/:clientId/shopping-carts/:shoppingCartId/product-items')

Thanks again for sharing.

Luciano Delucchi, thanks for the feedback and a good catch! Indeed the configuration would clash. I meant to use DELETE verb for removing product item. I adjusted the code (also to use query params for delete instead of body).
I need to write a dedicated article on how to shape task-based/DDDish REST API, as that implementation would be a bit different, it'd be either single POST endpoint with different types of operations, or just with method names in the end.

Thanks!
Looking forward to that task-based article.
Cheers!

Thanks for this, it's an amazing implementation of Event Sourcing with functional TypeScript. The only thing I would suggest is to remove the `default` handlers from the switch operators for a simple reason: if I add a new Command or Event type, I will get a compiler error if I don't add the case in the handler - considering here I'm using `noImplicitReturns`. That imo allows for further improvements in the model without the fear of missing some pattern matching.