Domain-Driven File Structuring -React/Redux

By Hassan Djirdeh

A blurb from Vaughn Vernon in Implementing Domain-Driven Design (2013) has a fantastic explanation to what Domain-Driven Design is:

The software development approach called Domain-Driven Design, or DDD, exists to help us more readily succeed at achieving high-quality software model designs. When implemented correctly, DDD helps us reach the point where our design is exactly how the software works.

To break it down further, DDD focuses on using a common Ubiquitous Language shared between domain experts and developers to structure an entire application through Domain Models. Domain Models are software models of a very specific business domain that you may find yourself working on. It’s often implemented as a small, very focused object model where the object has data and behaviour with accurate business meaning.

There are numerous benefits to DDD, ranging from a better understanding of the business, better organized code to even a better user experience. Fully implementing DDD is an iterative approach that continuously requires thought and effort between team members, domain experts and the business to converge to a common design approach. I by no means cover everything DDD related but I hope to show how I adopted a DDD approach in structuring a React/Redux application scaffold.

Domain-Driven React/Redux?

Forking through example scaffolds for React/Redux applications, I often find directories to structure themselves based on the nature of files (e.g. actions , components , reducers ). A directory for a simple shopping cart app may resemble something like this:

src/

actions/

CartActions.js

ProductActions.js

components/

Cart.js

Product.js

ProductList.js

containers/

CartContainer.js

ProductContainer.js

reducers/

CartReducer.js

index.js

ProductReducer.js

App.js

routes.js

A fairly straightforward scaffold. Now, if I find myself needing to add information for a new domain (e.g. the login domain that encompasses a user logging in); I would have to add files to the actions, components, containers and reducers sub-directories; which would yield something like this:

src/

actions/

CartActions.js

LoginActions.js <--

ProductActions.js

components/

Cart.js

Login.js <--

Product.js

ProductList.js

containers/

CartContainer.js

LoginContainer.js <--

ProductContainer.js

reducers/

LoginReducer.js <--

CartReducer.js

index.js

ProductReducer.js

App.js

routes.js

A feature change within a particular domain or the creation of a new domain would involve going through multiple subdirectories, which could lead to poor maintainability in the long run. For a large complicated application, this isn’t the most efficient way for file structuring.