Clean React with Feature-based Domain Driven Design

Let's build an enterprise react application with confidence. A well-structured react application in a testable and maintainable way, it's better on every level. It wouldn't hurt if the way you architect your React apps allows adding new features without a headache. We will have a good separation into layers, bringing beautiful traits, ease of navigation, and testability. Where we don't dump all our code into the UI or state management.

Domain-Driven Design - The Big Picture

There are a few things that couldn't fit on the diagram:

• Arrows represent the flow of data, which is either unidirectional or bi-directional.

• The domain layer is completely independent of all the layers. It's just pure data and business logic.

You will see on the diagram that domain-driven design has four layers (presentation, application, domain, and infrastructure). Each layer has a clear-cut responsibility.

Presentation

This layer is all the Components and also the state of the component. With Domain-Driven Design the UI is the dumbest part of the application. Its logic is limited to creating eye catchy UI for the user.

• Raw Data is strings, integers, or boolean values from the input fields.

• The state is a data representation in memory either object, array, string, integer, boolean, null, or undefined.

Application

This layer is the one to decide what to do next with the data(by managing subscriptions to infrastructure data streams). The application layer has only one job that is orchestrating all of the other layers. There is no UI code, network code, or storage code here. It doesn't perform any complex business logic.

• Immutable Slices/Hooks has a method that outputs a state. Slices come from the Redux Toolkit or RTK Query nonetheless you can use your preferred state management.

• Methods are simply a pure block of code that takes parameters and returns a value.

Domain

This layer is the pristine center of the application. It doesn't depend on any other layers and is not concerned with anything but doing its own job well and the home of Failures.

• Entities are pure classes that don't contain any business logic. It's just a pure object representation.

• Failures are simply a representation of errors

Infrastructure

This layer deals with APIs, databases, browser storage, and device sensors. The infrastructure layer is composed of two parts: low-level data sources and high-level repositories.

Data sources operate at a low level. The Remote data source fits JSON response from a server and the Local data source fetches data from local storage.

Repositories perform the important task of being the boundary between the domain and application layers and the ugly outside world.

Data Transfer Objects is a copy of the entities but is not pure classes. It can be messy sometimes; because will contain logic for transforming data like JSON or strings etc.

Folder Structure

Everything is about tradeoffs, there is no wrong way to organize your app.

This Feature-based domain-driven design is to make the developer start the development as fast as possible but to have a well-structured codebase with ease of maintainability in mind.

What is the sole purpose of the core folder in the main src directory? The core folder will have the four layers sub-folder; each layer of logic will be shared across the application with the corresponding layer of each feature.

And also, why is there a core folder in the blog folder? The purpose of the core folder in each feature is a place where you put all the logic that will be shared across the sub-features of the main feature. Like the blog folder post feature has two sub-features which are the post lists and post details. But it doesn't mean that every main feature will have a core folder; where sometimes it doesn't make sense at all. Only if you think the main feature has a large scope then is it a good fit to have a core folder for that feature. This will help you in the long run for maintaining each feature of the application. And you can easily re-use every feature for other projects.

Also, keep in mind that some features don't necessarily have all the layers. Notice the about-us folder only has a presentation layer.

There is nothing inherent about-us page logic, so it doesn't make sense to have other layers.

That's it, happy clean code!!!💩

Always remember the 3 M's when implementing a new feature of the app.

💻 Make it work; 
✅ Make it right then; 
🚀 Make it fast.

Catch me up on the next one Grade A Enterprise React Development Environment with ViteJS.