Quick Summary: Clean Architecture, Robert C. Martin
This will be a story about the impression of the book, as well as some concepts and knowledge that, thanks to this book, were studied
Can you, reading this publication, give a clear answer to the question, what is architecture? What is architecture in the context of programming and design? What role does she play? There are a lot of ambiguities in this term. And everything seems to be clear, but somehow abstract, and without accuracy. Martin believes, and I agree with him, that the application has two components:
But even if the application performs very well the task that it should perform, this does not mean at all that it has a good architecture. Architecture is not about application behavior. Architecture is about ease of changeability, architecture is about ease of deployment, architecture is about development independence. Architecture is about the speed with which understanding comes to a new person in a team
And here’s how to build this architecture, how to get rid of a headache with a small change in requirements from PM, or from a stakeholder: this is what the book will tell
Before I say anything about this book, I want to say a little about myself.
Right now I'm a Strong Junior Developer specializing in developing services through ASP .NET CORE.
I’ve been working on one “gallery” for a year now, and I seem to be doing a little
I already read this book 2 times, and I recommend it to everyone to read:
In general, to anyone who is at least somehow connected with the development of the PP, I mean the direct development of the various Salelov and PM's there, we don’t take them into account (although it would also be useful to know why a maid spends 2 times more time on a task), I advise you to read this book.
And now I’ll try to argue why I think so
A little about the author of this book (because for me the authority of the writer plays a big role). I think you will understand me, although this is not always correct, but if an authoritative person in the sphere says something to you, you show much more confidence in what he said. For example, I think you would rather believe in the diagnosis that the doctor puts to you than from some person from the crowd (google the symptoms)
Robert Martin - aka Ankle Bob (Uncle Bob) - has been working in the field of programming, and of various systems (from web services to embed systems), since 1970. He is a technical consultant and architect, he wrote in various technical journals, he is a very experienced programmer, and a person who played one of the key roles in creating the well-known SOLID principles (you can say the creator). Also, I want to add that my team leader with 15+ experience advised me on this book
Before reading the book, I read quite a lot of articles on the same Habré, where such a word as “dependence” appeared. What is it, who is dependent on whom, what exactly does it mean to “depend”, and how can some class depend on someone?
And as I read the book, I learned two points:
Dependency is a term meaning that some class (component, service) knows about some other class (component, service), and this knowledge at the code level is determined (now javists, sharpers, people will understand me) by a specific namespace import . In other words: you have a class A with a namespace Default.Classes and a class B Another.Classes. So, if the class A code appears using Another.Classes; - this means that class A depends on class B.
To understand according to the scheme where the dependent class is and where not - look at the direction of the arrow: 1) the arrow will point from class A in the direction of class B. This means that class B is more independent than class A. And the changes in class A , no “damage” to class B
One of the main reasons for reading this book was the explanation of SOLID principles from the original source, because Uncle Rob developed these principles and we can say that thanks to him we hear this name - SOLID.
For those who are not in the know - these principles are said and advised to design their applications in accordance with 5 rules:
S - SRP (Single responsibility principle)
O - OCP (Open-closed principle)
L - LSP (Liskov substitution principle)
I - ISP (Interface segregation principle)
D - DIP (Dependency Inversion principle)
All these principles can be applied at the level of classes and objects, at the level of modules and components, and at the level of rails (services).
If you think that the Single responsibility principle is about the fact that the class, or the module should do only one thing, then you should definitely read at least the chapter on Solid. For the definition given above is a consequence, but not the definition of the principle itself
I want to pay special attention to the explanation of the Dependency Inversion Principle (the one that D is from SOLID). As I read the book, I understood that this is not just a principle, it is also a mechanism and a tool with which you can change the direction of your dependencies and make, for example, business logic (DOMAIN) independent of the details of the implementation of the Data access layer (DAL'a)
Although the principle itself along with the others in SOLID means a little something other than the mechanism, the mechanism itself is used throughout the book, and this is one of the main methods to invert and change the direction of your dependencies, which by the way is used with DDD
Very often, the book will mention the principle of making important architectural decisions: which database to use, which framework to use, which library to connect, what to use as a search engine, etc.
So, the author believes: you should ASAP make this kind of decision. Because requirements can change, perfomance restrictions too, the behavioral component itself tends to change. During the development process, some solution may seem less effective than another, less convenient than another. And the strength of your architecture will determine how quickly and painlessly you can replace one technology with another (OCP says this by the way).
For example, all of a sudden, you decide to use MongoDb instead of Postgresql, or files in general, or use mocked data, the operations with which will be performed in memory. And under certain conditions - this may make it possible to rewrite almost all of the logic.
To prevent such situations, we can use some mechanisms that will push the decision-making time as far as possible. One of these mechanisms is abstraction.
DDD - Domain Driven Design - an approach to developing services with complex business logic, critical to changes, which is aimed at maximizing the understanding of project management positions (PMs, Sale managers etc), with rowers. That is, that there would be a ubiquitous language between all project members, and everyone could understand the other, and that everyone would think in the same domain with the same business rules.
If you are a supporter of DDD, or want to be one, or you don’t understand something about this, but want to understand, the book is a must-read, especially the second part of the book.
Here the author explains the existence of the Dependency Rule, and why, following it, you will build the correct application architecture. Why dependencies should follow towards High Policy components, why a domain (High Policy component) should be independent of the infrastructure and how it will simplify deployment and development for you
Uncle Rob also talks about how implementation details can harm your system and prevent it from evolving without pain in the future.
Remember!
DB is an implementation detail
Clients (Web, Mobile, etc) - implementation details
Frameworks are an implementation detail.
It is necessary to abstract as much as possible and not depend on it, using the Dependency Inversion described above with interfaces and abstractions, Dependency Rule and other mechanisms
I especially liked this section as a service developer on ASP .NET CORE. For it describes the methodologies for building a unified service architecture from ready-made components.
Robert described 4 possible layer separation schemes.
He made it clear why the so often used mechanism of the 3-layer architecture: UI (controllers), Services (Domain), DAL (Database) - is bad enough compared to others. I have not seen a lot of projects, but in each, for example, micro-service, on the back end, it uses a three-layer architecture.
Also, quite often, one-component-one-service architecture is used. In general, both of them are not bad, but it has a lot of disadvantages, in comparison, for example, how the architecture is built using DDD, especially when critical to change, and complex services.
In general, this review of the book has come to an end. I really liked the book itself, I do not regret what I read, thanks to the author. Thank you for your attention, dear readers, do not judge strictly - this publication is based on the impression of the book and my personal enthusiasm
UPDATE 1.0
During the discussions, it can be understood that the SUDDEN, and EASY change of storage will not be easy, one way or another. In some cases, even a very painful, and yet abstraction and encapsulation of access to the store, it is doubtful what will make the situation worse, but rather a little better, at least due to the independence of the variable component from the rest.
Architecture
Can you, reading this publication, give a clear answer to the question, what is architecture? What is architecture in the context of programming and design? What role does she play? There are a lot of ambiguities in this term. And everything seems to be clear, but somehow abstract, and without accuracy. Martin believes, and I agree with him, that the application has two components:
- Behavior (behavior) - functions and tasks that the program (component, service) performs.
- Architecture - this term is more about changing applications.
But even if the application performs very well the task that it should perform, this does not mean at all that it has a good architecture. Architecture is not about application behavior. Architecture is about ease of changeability, architecture is about ease of deployment, architecture is about development independence. Architecture is about the speed with which understanding comes to a new person in a team
And here’s how to build this architecture, how to get rid of a headache with a small change in requirements from PM, or from a stakeholder: this is what the book will tell
About Authors
Before I say anything about this book, I want to say a little about myself.
Right now I'm a Strong Junior Developer specializing in developing services through ASP .NET CORE.
I’ve been working on one “gallery” for a year now, and I seem to be doing a little
I already read this book 2 times, and I recommend it to everyone to read:
- developers of embeded systems;
- front endchikers;
- back-endors;
- and even devopsam.
In general, to anyone who is at least somehow connected with the development of the PP, I mean the direct development of the various Salelov and PM's there, we don’t take them into account (although it would also be useful to know why a maid spends 2 times more time on a task), I advise you to read this book.
And now I’ll try to argue why I think so
A little about the author of this book (because for me the authority of the writer plays a big role). I think you will understand me, although this is not always correct, but if an authoritative person in the sphere says something to you, you show much more confidence in what he said. For example, I think you would rather believe in the diagnosis that the doctor puts to you than from some person from the crowd (google the symptoms)
Robert Martin - aka Ankle Bob (Uncle Bob) - has been working in the field of programming, and of various systems (from web services to embed systems), since 1970. He is a technical consultant and architect, he wrote in various technical journals, he is a very experienced programmer, and a person who played one of the key roles in creating the well-known SOLID principles (you can say the creator). Also, I want to add that my team leader with 15+ experience advised me on this book
About the book
Dependencies
Before reading the book, I read quite a lot of articles on the same Habré, where such a word as “dependence” appeared. What is it, who is dependent on whom, what exactly does it mean to “depend”, and how can some class depend on someone?
And as I read the book, I learned two points:
Dependency is a term meaning that some class (component, service) knows about some other class (component, service), and this knowledge at the code level is determined (now javists, sharpers, people will understand me) by a specific namespace import . In other words: you have a class A with a namespace Default.Classes and a class B Another.Classes. So, if the class A code appears using Another.Classes; - this means that class A depends on class B.
To understand according to the scheme where the dependent class is and where not - look at the direction of the arrow: 1) the arrow will point from class A in the direction of class B. This means that class B is more independent than class A. And the changes in class A , no “damage” to class B
SOLID
One of the main reasons for reading this book was the explanation of SOLID principles from the original source, because Uncle Rob developed these principles and we can say that thanks to him we hear this name - SOLID.
For those who are not in the know - these principles are said and advised to design their applications in accordance with 5 rules:
S - SRP (Single responsibility principle)
O - OCP (Open-closed principle)
L - LSP (Liskov substitution principle)
I - ISP (Interface segregation principle)
D - DIP (Dependency Inversion principle)
All these principles can be applied at the level of classes and objects, at the level of modules and components, and at the level of rails (services).
If you think that the Single responsibility principle is about the fact that the class, or the module should do only one thing, then you should definitely read at least the chapter on Solid. For the definition given above is a consequence, but not the definition of the principle itself
About Dependency Inversion
I want to pay special attention to the explanation of the Dependency Inversion Principle (the one that D is from SOLID). As I read the book, I understood that this is not just a principle, it is also a mechanism and a tool with which you can change the direction of your dependencies and make, for example, business logic (DOMAIN) independent of the details of the implementation of the Data access layer (DAL'a)
Although the principle itself along with the others in SOLID means a little something other than the mechanism, the mechanism itself is used throughout the book, and this is one of the main methods to invert and change the direction of your dependencies, which by the way is used with DDD
About making architectural decisions
Very often, the book will mention the principle of making important architectural decisions: which database to use, which framework to use, which library to connect, what to use as a search engine, etc.
So, the author believes: you should ASAP make this kind of decision. Because requirements can change, perfomance restrictions too, the behavioral component itself tends to change. During the development process, some solution may seem less effective than another, less convenient than another. And the strength of your architecture will determine how quickly and painlessly you can replace one technology with another (OCP says this by the way).
For example, all of a sudden, you decide to use MongoDb instead of Postgresql, or files in general, or use mocked data, the operations with which will be performed in memory. And under certain conditions - this may make it possible to rewrite almost all of the logic.
To prevent such situations, we can use some mechanisms that will push the decision-making time as far as possible. One of these mechanisms is abstraction.
DDD references
DDD - Domain Driven Design - an approach to developing services with complex business logic, critical to changes, which is aimed at maximizing the understanding of project management positions (PMs, Sale managers etc), with rowers. That is, that there would be a ubiquitous language between all project members, and everyone could understand the other, and that everyone would think in the same domain with the same business rules.
If you are a supporter of DDD, or want to be one, or you don’t understand something about this, but want to understand, the book is a must-read, especially the second part of the book.
Here the author explains the existence of the Dependency Rule, and why, following it, you will build the correct application architecture. Why dependencies should follow towards High Policy components, why a domain (High Policy component) should be independent of the infrastructure and how it will simplify deployment and development for you
Abstraction
Uncle Rob also talks about how implementation details can harm your system and prevent it from evolving without pain in the future.
Remember!
DB is an implementation detail
Clients (Web, Mobile, etc) - implementation details
Frameworks are an implementation detail.
It is necessary to abstract as much as possible and not depend on it, using the Dependency Inversion described above with interfaces and abstractions, Dependency Rule and other mechanisms
Methods for building modules
I especially liked this section as a service developer on ASP .NET CORE. For it describes the methodologies for building a unified service architecture from ready-made components.
Robert described 4 possible layer separation schemes.
He made it clear why the so often used mechanism of the 3-layer architecture: UI (controllers), Services (Domain), DAL (Database) - is bad enough compared to others. I have not seen a lot of projects, but in each, for example, micro-service, on the back end, it uses a three-layer architecture.
Also, quite often, one-component-one-service architecture is used. In general, both of them are not bad, but it has a lot of disadvantages, in comparison, for example, how the architecture is built using DDD, especially when critical to change, and complex services.
In general, this review of the book has come to an end. I really liked the book itself, I do not regret what I read, thanks to the author. Thank you for your attention, dear readers, do not judge strictly - this publication is based on the impression of the book and my personal enthusiasm
UPDATE 1.0
During the discussions, it can be understood that the SUDDEN, and EASY change of storage will not be easy, one way or another. In some cases, even a very painful, and yet abstraction and encapsulation of access to the store, it is doubtful what will make the situation worse, but rather a little better, at least due to the independence of the variable component from the rest.
All Articles