Crux Learnings.
Published in

Crux Learnings.

Introduction to Clean Architecture

We have to make a small change to the company´s flagship software, on which most of the operation of our business depends, therefore our livelihood, that of our peers and all the families we represent.

The development team is nervous, stress is perceived throughout the organization, they fear that, as has happened on previous occasions, the move to production fails, the system stops working, or worse, that the system runs today and tomorrow unimaginable incidents will appear, code parts that they did not know and therefore result in irrecoverable losses, both image and monetary.

Laura is the only one who looks optimistic, she is the junior developer, who has been on the project for only a month, believes that the lines developed for this release are negligible compared to the millions of lines of code that the entire solution has, believes that the months of development represent too much time for something that, if she did it with a project from scratch, it would take him up to half the time.

Mike, one of the few senior developers that the company could sustain, knows that the system is in a palliative state, every line that is added is a step closer to total collapse, resembles a giant castle of card that by putting a card more all will come to the ground at any time.

Mike is aware that he has been inherited from a disastrous solution, which was developed under a lot of pressure, with a data-oriented architecture. You tried to create automated unit tests, but with the current architecture it is impossible for you.

This is a scenario I have heard many times and I have even lived it in my own flesh. Since I started practicing my career more than a decade ago, I have always worked in outsourcing companies so I have developed and given maintenance to very diverse projects, and mostly with a traditional data-oriented architecture.

It is very common worldwide and as Robert C. Martin describes it in his book “Clean Architecture”, published late last year, which through the following graphs describes the problem.

Cost per line of code over time.
Developmental productivity by release.
Monthly development cost per release.

The importance of these charts is to make us aware that something is not right with the traditional ways of developing, and that we need to evaluate better architectures.

“The goal of software architecture is to minimize the human resources required to build and maintain the required system”

Uncle Bob has been a strong evangelist for SOLID and TDD compiling a set of trends and best practices in his books, creating the concept of Clean Architectures as an architecture oriented to the rules of business, with its main influences based on:

· Hexagonal Architecture (a.k.a. Ports and Adapters) por Alistair Cockburn, Steve Freeman, y Nat Pryce

· Onion Architecture por Jeffrey Palermo

Characteristics

As uncle Bob points out in the summary article of “The Clean Architecture”, clean architectures comply with the following features and principles:

· Independent of Frameworks: the architecture should not depend on or see it is influenced by the constraints or functions of frameworks

· Testable: the architecture should give you the ability to test business rules without thinking about database, graphical interface or other non-essential components of the system

· Independent of the UI: if the UI changes often this can´t affect the rest of the system, it has to be independent

· Database-independent: we should be able to change the Oracle database engine, to Mongo DB, to SQL server, to big table to CouchDB or any other database without affecting our system too much

· Independent of any external entity: in fact, the rules of your business simply know nothing about the outside world

Principles related to cohesion

· The Reuse/Release Equivalence Principle: this principle of cohesion proposes that components should be able to be deployed independently without affecting other

· The common closure principle: the idea of this principle is to group clases that can change for the same reason into a single component

· The common reuse principle: if one component dependes on another, you have to try to make it because it needs all the classes that make up it

Principles related to coupling

· The Acyclic Dependencies Principle: this principle refers to dependencies, which indicates that the change in a component, should not trigger the need to make chain changes to other artifacts, which force the initial component to be modified again

· The Stable Dependencies Principle: the principle indicates that a component that changes often should not depend on another that is difficult to modify, because it will also be difficult to modify

· The stable Abstractions Principle: this principle tells us that if a component of our system is going to change little, because it is difficult to modify it, it must be composed of abstract classes and interfaces. In this way the component will be easily extensible, and it won´t affect the rest of the architecture that much

The art of developing software, dating back to the middle of the last century, has gone through a myriad of continuous improvements, and today, we have the challenge of creating maintainable and testerable software, so we need to gain k in these areas and try to apply it to our developments.

Implementing clean code architectures is not a magic recipe, or a guide to one-off steps that will lead us to success in developing systems, we can summarize it as a set of well-applied principles that help us ensure positive results as Laura expects them and build trust in Mike to inherit scalable systems.

We must be critical and understand that not all projects are the same, so we need to analyze them, evaluate them and make architecture-design decisions according to the above requirements. We have not yet discovered the perfect architecture, therefore we must continue to study to make the best decision based on the means we have, technologies/trends offered by the market and experiences, all with the objective of achieving quality products, in times of competitive response and with excellent results that promote our work.

rbarrantes@cruxconsultores.com

Created by: Roberto Barrantes.

Learn more about Crux: Website · LinkedIn · Facebook · Twitter

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store