What’s Clean Architecture?
Clean Architecture represents a collection of patterns, practices and principles used to create modern, high quality and elegant software systems that are simple to understand, flexible, testable and maintainable. Clean Architecture is a robust alternative to the traditional 3-layer database centric architecture, which has been used for decades and is well-known for its limitations.
But what is Software Architecture?
Let’s take an example from classic architecture. Suppose you want to build a house. Do you start building some walls, paint them green ? Of course not. You first need to define the shape of the house, it’s outward appearance, decide where the main entrance will be, plan the layout of the rooms and so on. Architecture is about taking a series of decisions in order to fulfill your need: comfortable house to live in.
Software architecture is not very different from classical architecture – it’s still about carefully combining low and high level decisions to build something that creates business value. But in case of Software Systems, the final product is something concrete, but rather something more abstract : an Application.
What is the purpose of Software Architecture?
The primary purpose of Software Architecture is to support the life cycle of a system. Given that the main phases of software development have remained the same for the last decades, a good Architect will create a system that is easy to understand, fun to develop, quick to deploy, a pleasure to operate and a joy to maintain. The ultimate goal of Software Architecture, is to minimize the lifetime cost of a software system, while maximizing overall programming efficiency.
The goal of Software Architecture
As Robert Martin (the author of the book “Clean Architecture”) stated: “The goal of Software Architecture is to minimize the human resources required to build and maintain the required system”.
One simple metric that can be used to determine the quality of a software architecture is to measure the effort required to meet the the customers’ requirements. If the effort is low and continues to stay so during the lifetime of the system, then the architecture of that particular system is good. On the contrary, if that effort increases with each and every release, the architecture is bad and it will most probably become the reason why the system will die.
The strategy of Clean Architecture towards this purpose
The strategy behind the power of clean architecture is leaving as many options open, for as long as possible. One of the greatest misconceptions in building software systems is to create something that just “works”, and this implies making lots and lots of emotionally driven decisions. While it is true that they might seem to work fine, most of these systems have problems in other areas such as ongoing development, deployment and maintenance (the latter being the most expensive). Clean Architecture acknowledges the critical role of proper system behavior, while considering the its overall health.
How does it actually work?
Software provides two main types of value: behavioral and structural. Behavior value is given by how the system behaves under certain circumstances, while structural value derives from the fact that the structure of a system can be easily change and adapted to new business needs. The latter is more important because it’s what makes software soft (i.e. easy to change).
Thus a soft software system that can quickly adapt to new requirements is of more value than one with a rigid structure which doesn’t allow agility to come into play. Consequently, the way to keep software soft is to keep options open for as long as possible.
Keeping options open?
Every software system out there can be decomposed into two major elements: Policy and Details. While policies define the “why” and “what” needs to be done, details specify “how” things should be done. Policies concern behavior, while details concern the structure through which the policies are implemented on machines.
Therefore Policies is where the real value of a system lies, while details help policies come alive, in the form software products (i.e. software applications).
What does this actually mean?
Is deferring really that important?
Truth be told, the more you wait on making a decision, the better that decision will be. The longer you wait before taking a decision about details, the more experiments you can try. The more experiments you can run, the more information of value you will gain. Ultimately, the more information you have on a certain topic, the better the decision will be in the long run.
The good architect will understand and separate policies from details to the point that the Policy has no knowledge of the details and doesn’t depend on them in any way. Moreover, he will enforce Policy design in a way that décisions about low-level details can be deferred for as long as possible, thus maximizing the number of décisions not made.