Clean architecture in web applications: practical principles
Separating domain, application and infrastructure so the product can change without being rewritten.
What problem it solves
In many applications the business logic ends up mixed with database calls, interface code and third-party details. Changing a provider or a rule becomes surgery.
Clean architecture proposes layers with dependencies pointing in one direction: the domain does not know about the database or the framework; the infrastructure does know the domain.
Start with the domain
Define the entities and rules that make sense even without a website: an order cannot move to "shipped" before it is paid, a discount expires on a specific date. Those rules should be testable without starting a server.
Interfaces (ports) describe what the application needs, for example saving orders, and the infrastructure implements them with the provider you choose.
When you do not need it
For a presentation page or a simple form, a full domain layer is over-engineering. The separation pays off when business rules change, there are several external integrations, or a team needs to work in parallel.
The practical rule: add layers when the cost of changing something is clearly higher than the cost of the separation.