Clean Architecture: The Secret To Flexible Apps

Architecture Implementations

There are many architectures that implement the clean architecture design:

1. Hexagonal Architecture by (a.k.a. Ports and Adapters) by Alistair Cockburn.
2. Onion Architecture by Jeffrey Palermo.
3. DCI from James Coplien, and Trygve Reenskaug.
4. BCE by Ivar Jacobson from his book Object Oriented Software Engineering: A Use-Case Driven Approach.

Though these architectures all vary somewhat in their details, they are very similar. They all have the same objective, which is the separation of concerns. They all achieve this separation by dividing the software into layers. Each has at least one layer for business rules, and another for interfaces.

Benefits of Clean Architecture

1. Framework Independence: Unlike frameworks that dictate how to structure your code, Clean Architecture empowers you to treat them as tools. You can leverage them without being constrained by their limitations.
2. Enhanced Testability: Business rules can be comprehensively tested in isolation, independent of external dependencies like databases or user interfaces.
3. UI Independence: The user interface can be revamped without impacting the core business logic. Imagine switching from a web UI to a console UI without rewriting the core functionalities.
4. Database Agnosticism: Clean Architecture liberates you from being tied to a specific database. You can effortlessly migrate from Oracle to PostgreSQL or any other database system without affecting your business rules.
5. External Agency Insulation: Business rules remain entirely oblivious to external factors, simplifying maintenance and promoting loose coupling.

All of these points contribute to a smoother development, deployment, and maintenance process for your software system.

The Dependency Rule: Core to Clean Architecture

Imagine concentric circles, each representing a distinct software layer. As you move inwards, the layers become more abstract and policy-driven. The outer circles embody mechanisms, while the inner circles represent policies.

The Dependency Rule, the cornerstone of Clean Architecture, dictates that dependencies must always point inwards. Inner circles must remain entirely ignorant of anything residing in outer circles. This includes functions, classes, variables, and any other named software entity. Data formats employed in outer circles should also be kept out of inner circles, especially if they’re generated by external frameworks. The objective here is to shield inner circles from any potential changes or influences arising in outer circles.

Architecture Details

• Entities: Encapsulate business rules that hold true across the entire enterprise. An entity can be an object with methods or a collection of data structures and functions. The key is that these entities are reusable by various applications within the organization.
• Use Cases: This layer harbors application-specific business rules. It orchestrates the flow of data to and from entities, leveraging their enterprise-wide business rules to fulfill the use case’s objectives.
• Interface Adapters: This layer comprises adapters that transform data between the formats preferred by use cases and entities, and the formats necessitated by external systems like databases or web frameworks. This layer would house the MVC architecture of a typical GUI. Presenters, Views, and Controllers all reside here. Models likely function as data structures passed between controllers and use cases, and vice versa between use cases and presenters/views.
• Frameworks and Drivers: The outermost layer typically consists of frameworks and tools like databases, web frameworks, etc. You generally write minimal code in this layer besides the glue code that interacts with the adjacent inward circle. This layer encapsulates all the technical minutiae. The database and web framework are mere details, deliberately placed on the periphery to minimize their impact on the core system.