This will be a story about the impression about the book, and also some of the concepts and knowledge that, thanks to this book, have been studied will be considered.
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 quite a few ambiguities in this term. And everything seems to be clear, but somehow abstract, and without precision. Martin believes, and I agree with him, that the application has two components:
- Behavior - functions and tasks that the program (component, service) performs.
- Architecture is a term more about changing the application.
But even if an application performs the task it is supposed to perform very well, this does not mean at all that it has a good architecture. Architecture is not about application behavior. Architecture is about ease of change, 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 the headache with a small change in requirements from the PM, or from the stakeholder: this is what the book will tell
About the authors
Before I say anything about this book, I want to say a little about myself.
I am currently a Strong Junior Developer specializing in service development with ASP .NET CORE.
I have been working at the same “gallery” for a year now, and I seem to be coping a little
I have already read this book 2 times, and I recommend reading it to everyone:
- developers of embeded systems;
- front-end workers;
- back-end workers;
- and even devops.
In general, for everyone who is at least somehow connected with the development of software, I mean the direct development of different Sales and PMs there (although it would also be useful to know why a maid sometimes spends 2 times more time on a task), I advise you to read this book.
And now I will 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 field tells you something, you show much more confidence in what he said. For example, I think you will believe more in the diagnosis that the doctor gives you than from some person from the crowd (googled the symptoms)
Robert Martin - aka Uncle Bob (Uncle Bob) - has been working in the field of programming, and different systems (from web services to embedit systems), since 1970. is a technical consultant and architect, has written for various technical magazines, is a very experienced programmer himself, and a person who played one of the key roles in the creation of the well-known SOLID principles (one might say the creator). Also, I would like to add that this book was recommended to me by my team leader with 15+ work experience
About the book
Addictions
Before reading the book, I read quite a lot of articles on the same Habré, where such a word as “addiction” appeared. What is it, who is dependent on whom, what exactly does “depend” mean, and how can a class depend on someone?
And as I read the book, I learned two things:
Dependency is a term that means that some class (component, service) knows about some other class (component, service), and this knowledge at the code level is determined (now javaists, sharpists, sishniki will understand me) by a certain namespace import . In other words: you have class A with the namespace Default.Classes and class B Another.Classes. So, if using Another.Classes appears in the source code of class A; - this means that class A depends on class B.
To understand from the diagram where the dependent class is and where it is not, look at the direction of the arrow: in 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 changes in class A , no “damage” to class B will be caused
SOLID
One of the main reasons for me to read this book was to explain the SOLID principles from the 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 speak and advise you to design your 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 links (services).
If you think that the Single responsibility principle is about the fact that a class, or a module should do only one thing, then you definitely need to read at least the chapter on Solid. For the definition given above is a consequence, but not a 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 from SOLID'a). In the course of reading 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 implementation details of the Data access layer (DAL)
Although the principle itself along with the rest in SOLID means a little different 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 in 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 include, what to use as a search engine, etc.
So, the author believes: you should make AS LESS as possible such decisions. For requirements can change, performance restrictions too, the behavioral component itself tends to change. During the development process, one solution may seem less efficient 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, operations on which will be performed in memory. And under certain conditions, this can force you to rewrite almost all the logic.
To avoid such situations, we can use some mechanisms that will push the decision time as far as possible. One of these mechanisms is abstraction.
References to DDD
DDD - Domain Driven Design - an approach to the development of services with complex business logic, critical to changes, which is aimed at maximizing the understanding of project management positions (PMs, Sale managers, etc), with ordinary rowers. That is, so that there is a ubiquitous language between all project members, and everyone can understand the other, and so that everyone thinks 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 it, 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 will help you build the correct application architecture. Why dependencies should flow toward High Policy components, and why domain (High Policy component) should be infrastructure-independent and how this will simplify your deployment and development
Abstraction
Uncle Rob also talks about how implementation details can harm your system and keep it from evolving without pain in the future.
Remember!
The database is an implementation detail
Clients (Web, Mobile, etc) - implementation details
Frameworks are an implementation detail
From all this, you need to abstract as much as possible and not depend, using the above-described Dependency Inversion with interfaces and abstractions, Dependency Rule and other mechanisms
Module building methods
I liked this section especially strongly, as a developer of services on ASP .NET CORE'e. For here they talk about 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 commonly used mechanism of 3-layer architecture: UI (controllers), Services (Domain), DAL (Database) is rather bad compared to others. I have not seen very many projects, but in each, for example, a micro-service, on the back-end, exactly a three-layer architecture is used.
Also, quite often, a one-component-one-service architecture is used. In general, they are both good, but it has a lot of disadvantages, in comparison, for example, how the architecture is built when using DDD, especially with critical changes and complex services.
So, this is the end of this book review. I really liked the book itself, I do not regret reading it, thanks to the author. Thank you, dear readers, for your attention, do not judge strictly - this publication is based on the impression of the book and my personal enthusiasm
Source: habr.com
