4 comments

[ 61.7 ms ] story [ 2116 ms ] thread
Routers can and should be independent of View technology. Here's one that works well for React but is independent of React:

https://github.com/Rajeev-K/mvc-router

The MVC model is well-understood, and does not require Redux. MVC does not imply two-way data binding, btw.

Nice! Thanks for commenting. The reason that I tied the two together for react is that it saves quite a bit of boilerplate to let the router pass on the application service than having to manually add the service to each page individually.

However, the route and router are not necessary for the rest of the library to work and the rest of the library can be used as a plugin to use with a different router.

In terms of DDD principles - if you have decided you might need CQRS for your particular case, you might not want to spend a large amount of time setting up the routing/CQRS framework and you might want to spend all of your time on your actual business logic instead.

I am currently using this in a few of my projects and it's proving quite neat, although I may still need to add some details. I hope others can find it useful - if not, then at least this was a worthwhile experiment.

You should probably remove "Event Sourcing" from the description ... CQRS has nothing to do with Event Sourcing (even though they are often used in conjunction with each other), nor does your library from what I can tell.
You are right that CQRS doesn't have to use Event Sourcing... but this library DOES use Event Sourcing, although it seems the events are called "Actions".