🧱 1. Independence of Frameworks
Your business rules should not depend on any framework. Frameworks are tools, not the core of your application.
You should be able to swap frameworks with minimal impact on business logic.
🧠 2. Testability
Business rules should be testable without the UI, database, web server, or other external elements.
Entities and use cases should be unit-testable in isolation.
🔄 3. UI, DB, and External Agents Are Details
The user interface and data storage are considered implementation details, and they should plug into your core application, not the other way around.
🧭 4. Separation of Concerns (Layers)
Clean Architecture typically follows a layered model. From innermost to outermost:
a. Entities
Encapsulate Enterprise-wide business rules.
Examples: domain objects like Invoice, User, Payment, etc.
b. Use Cases (Application Business Rules)
Orchestrate the flow of data to/from the entities.
Define application-specific business rules.
c. Interface Adapters
Convert data from the format most convenient for the use cases and entities to the format used by the external agents like databases, UI, etc.
Example: Controllers, Presenters, Repositories.
d. Frameworks & Drivers
The outermost layer that includes tools like Spring, Django, React, databases, etc.
🔁 5. Dependency Rule
Code dependencies must always point inward (from outer layers to inner ones).
Inner layers should not know anything about outer layers.
🔄 6. Inversion of Control / Dependency Inversion
High-level modules (e.g., use cases) should not depend on low-level modules (e.g., repositories).
Both should depend on abstractions (interfaces).
The outer layer implements the interfaces, and the inner layer depends on them.
📦 7. Boundaries & Interactors
You define clear boundaries between layers using interfaces and data transfer models.
This helps keep each layer decoupled and flexible.