Clean Architecture -> PART I: Introduction
In this article, I summarized the book “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” by Robert C. “Uncle Bob” Martin. The article consists of 5 parts and 27 chapters in total. Also all titles are used the same as in the book. Therefore, you can read from the book using the same title for more information.
Nowadays, even high school children can write a program and make it work. The code they wrote is probably not very good, but it works.
However, writing code and developing software is a completely different task. When the software is written correctly, the same work can be done using only a part of the human resources required to create and maintain it. This makes changes simple and quick. By reducing the required effort to minimum, functionality and flexibility can be maximized.
Chapter 1: What is Design and Architecture
For years, the semantic difference between design and architecture has been discussed. However, it can be said that there is no difference between these concepts.
Architecture is generally defined as a context used to purify high level from lower level detail; design is defined as lower level implementation of decisions and structures. Whereas low-level details and high-level structures are part of the system. Without one, the other cannot be used, nor is there a line that can separate them.
Chapter 2: A Tale of Two Values
There are two different values that each system provides to related places, behavior and structure. Software developers are obliged to ensure that the system will be developed by meeting these two values at high level. However, software developers often focus on one more than the other during development. Unfortunately, this makes the software system worthless.
1. Behavior
The machines requested by the persons concerned are coded by the developers to meet the requirements. When the machine violates these requirements, the developer tries to detect and resolve the bugs of this system. Most developers think that the job is to implementation and solve bugs according to requirements. However, this idea is wrong.
2. Architecture
Software is developed to make the system “soft”. The soft concept mentioned here is that the behavior of the system can be easily changed. If stakeholders decide to change a feature, this change should be made in a simple way.
The changes requested by the persons concerned are seen as simple changes in the same area, whereas on the developer’s side these are seen as pieces that need to be placed in the puzzle. Since the shape of the system does not match the shape of the request, each new request can be placed more difficult than the previous one.
The author used the concept of “shape” as a metaphor. This is because software developers are often forced to insert square nails into round holes.
1. Eisenhower’s Matrix
President Dwight Eisenhower presented a matrix about the importance and urgency of a business. He said the following about this matrix: “I have two kinds of problems, urgent and important. The urgent ones aren’t important and the important ones will never be urgent.”
This word is used today as an old saying. Things that are urgent are seldom important, and jobs that are important occasionally become urgent.
● The initial value of a software — behavior — is an urgent need, but not always particularly important.
● The second value of the software — architecture — is important, but will never be particularly urgent.
Of course, there will be both urgent and important, or both non-urgent and non-important. We can list them in order of importance:
▪ 1. Urgent and important
▪ 2. Not urgent and important
▪ 3. Urgent and not important
▪ 4. Neither urgent nor important
It should be borne in mind that the architecture of a code — because it is important — is in the top two in the list, and behavior — as urgent — in the first and third.
Common error during development is due to poor separation of first and third rows. This problem is due to the neglect of the important features of architecture and focusing on the development of a feature that may be useful to the system.
In summary, if architecture comes last, the system’s development will be costlier than it should be and it will be almost impossible to make changes to the system. If this was allowed to happen, this shows that the software development team did not struggle hard enough to design architecture correctly.
You can access the next section from the link below.
