Clean Architecture

We’ve reached the climax of our journey into software architecture. Today we’ll discover Clean Architecture.

Previously, I’ve described problems with architecture: No/Low discernable structure in a system, which often happens as software gets older and becomes a Legacy system. Another problem can be the very core of a system depending on the peripheral detail.

We are looking for a pervasive structure, an architecture, in our bespoke software systems whereby we can make changes quickly and cheaply.

Robert C. Martin (aka Uncle Bob) has written extensively on just such a system design: The Clean Architecture. I recommend reading his blog post on Clean Architecture. In my opinion, Uncle Bob’s book ‘Clean Architecture‘ is the best book on software architecture.

Other names for Clean Architecture are Onion Architecture and Hexagonal architecture, to name two.

I will try and explain Clean Architecture in simple terms today and in subsequent blog posts.

OK, let’s get started.

This diagram shows the logical structure of a system using Clean Architecture principles:

Clean Architecture has some exciting features:

Business Logic

Business Logic lives at the centre of the architecture. It’s the most critical part. Business Logic describes conceptual human interactions that are usually hundreds or even thousands of years old: registering a customer, placing an order for goods or services, paying for goods or services, and so on.

In the innermost circle, we have Entities—objects encapsulating enterprise-wide business rules. E.g. A customer number is made up of 9 digits.

The next circle contains use cases. Use cases describe business logic workflows—the consecutive steps the application must perform to fulfil a business requirement. For example, when registering a new customer, the workflow may be:

Validate the customer registration data,
Validate whether the customer already exists in the system,
If the customer already exists, stop the workflow, else
Transpose the customer registration data to a customer record and construct a customer number, and
Save the customer to a registry or other persistence medium.
Done!

Business logic is about high-level policy, i.e., what we are doing, and not concerned with the details, i.e., how we are doing them.

Adapter Interfaces

The next circle comprises the Adapter Interfaces. These connect the business logic use cases to specific implementations. For example, suppose the application data is stored in a SQL Server database. In that case, this adapter interface represents the SQL ORM mapper and the mapping code converting the ORM models to the business logic models.

Any changes to the database schema would be isolated to this adapter code, thus protecting the business logic from such detail.

Frameworks & Devices

The outermost circle represents the SDKs, frameworks, libraries, and other details that we need to connect to and communicate with external services or hardware devices. In our SQL Server database example, this would be the generalised code that allows us to connect to, read from and write to any SQL Server database.

Conclusion

Clean Architecture is a revolutionary approach to structuring our applications. It is aligned with the idea that the most stable parts of our system are more central and are kept independent from the more volatile, mechanism-oriented peripherals of our application. The scope of changes forced onto a system by changes in business requirements minimises the cost of maintaining the system.

Tomorrow, we’ll take a look at the Dependency Rule, a critical component of Clean Architecture.