As projects grow bigger, the code tends to get messy if there is no clear structure. I have worked on projects where everything was mixed together, and making a small change in one place would break something completely unrelated. Clean architecture is an approach to organising code so that each part has a clear responsibility and changes in one area do not ripple through the entire codebase.
\nThe core idea is to separate the code into layers, where each layer has a specific job. A common way to organise this is:
\nPresentation layer handles the UI. In a React app, this would be the components, pages, and anything related to what the user sees and interacts with.
\nBusiness logic layer contains the rules and logic of the application. For example, how to calculate a discount, what conditions must be met before placing an order, or how to validate user input beyond simple format checking.
\nData layer handles communication with external sources like APIs, databases, or local storage. This includes the fetch calls, data transformations, and error handling for external requests.
\nWhen these layers are mixed together, we end up with components that fetch data, apply business rules, and render the UI all in one place. This makes the component hard to test because we cannot test the business logic without rendering the UI. It also makes it hard to reuse the logic because it is tied to a specific component.
\nBy separating them, we can test the business logic independently, reuse it across different components, and swap out the data source without touching the rest of the code.
\nInstead of putting everything in a React component:
\nfunction OrderPage() {\n const [orders, setOrders] = useState([]);\n \n useEffect(() => {\n fetch(\"/api/orders\")\n .then(res => res.json())\n .then(data => {\n const filtered = data.filter(o => o.status !== \"cancelled\");\n const sorted = filtered.sort((a, b) => b.total - a.total);\n setOrders(sorted);\n });\n }, []);\n \n return <OrderList orders={orders} />;\n}We can separate it:
\n// data layer\nfunction fetchOrders() {\n return fetch(\"/api/orders\").then(res => res.json());\n}\n\n// business logic\nfunction getActiveOrdersByTotal(orders) {\n return orders\n .filter(o => o.status !== \"cancelled\")\n .sort((a, b) => b.total - a.total);\n}\n\n// presentation\nfunction OrderPage() {\n const [orders, setOrders] = useState([]);\n \n useEffect(() => {\n fetchOrders().then(data => {\n setOrders(getActiveOrdersByTotal(data));\n });\n }, []);\n \n return <OrderList orders={orders} />;\n}The component is now simpler. The fetch logic and business logic can be tested on their own. If the API endpoint changes, we only update the data layer. If the filtering rules change, we only update the business logic.
\nA simple folder structure that reflects this separation could look like:
\nsrc/\n components/\n pages/\n services/\n utils/\n hooks/services for the data layer, utils for shared business logic, hooks for reusable stateful logic, and components and pages for the presentation layer. The exact structure depends on the project size, but the principle stays the same: keep each layer in its own place.