I am at the beginning of an enterprise level application with 2 years of developing in front of me, and I was wondering how to organize my code while having in mind that the project will be huge and long.

I have created an architecture that I currently believe has potential but I’m not sure since I wasn’t able to find anybody that writes code that way, and also it’s against the paradigm that you can find in redux-toolkit documentation.

Let’s start with a short explanation on what I am trying to achieve. I want to make redux-toolkit easily replaceable in the future. I want to write 80% of my code decoupled from react and redux-toolkit and only look at them like external libraries, one for presentation layer and other for state management. I won’t go into details about the application, domain and infrastructure separation. I think you can find many articles and blogs easily about DDD and clean architecture. Let’s see what I have so far, this is the plan:

This is the big picture, so ui layer(component) fires redux-toolkit action / custom hook / custom action/ someOtherLib action. Actions have a responsibility to inject setState and getState callbacks (that IStateManagment domain Interface requires) and also responsibility to call certain usecases.

After this happens, usecase (userStory) gets a copy of the state from getState callback and implements all of the business logic (mutates state copy) and at the end calls setState callback. It also has a dependency on the domain layer, that contains model and logic attached to that model. And finally reducer detects action fired from setState callback and stores new state to the state management.

I would also like to share more on how I’ve implemented this with redux-toolkit and custom hook local store (I’ve also implemented this with custom store implementation but I won’t talk about that, but you can find it on github).

I’ve implemented multiple state management stores on purpose to test how easily I can replace it inside my react components.

This is the implementation of dispatching (or calling custom hook for localstate):

Next is Domain state management interface, it defines what must be provided by external state management:

Next is calling the usecase, action creators have a responsibility to call certain usecases:

After that we have a usecase where all the business logic is implemented in one place:

And at the end single reducer to handle setState action:

You can find whole projects with 3 different state managements on github: https://github.com/WingsDevelopment/react-clean-architecture

I know this is much, but I tried to share this as clear as possible. I am concerned about making the decision to go down this road. I am not sure what are cons of this approach and if I am missing something and if so, what?