This will be a narrative about my impressions of the book, and it will also cover some concepts and knowledge that were explored through this book.
Architecture
Can you provide a clear answer to the question, what is architecture? What is architecture in the context of programming and design? What role does it play? There is quite a bit of ambiguity around this term. It seems straightforward, yet somewhat abstract and lacking precision. Martin believes, and I agree with him, that an application has two components:
- Behavior — the functions and tasks that the program (component, service) performs.
- Architecture — this term is more about the changes to the application.
However, even if an application executes the task it is supposed to perform very well, that does not mean it has a good architecture. Architecture is not about the behavior of the application. Architecture is about ease of change, architecture is about ease of deployment, architecture is about independent development. Architecture is about the speed at which understanding comes to a new person on the team.
And here’s how to build this architecture, how to relieve the headache when there are minor changes in requirements from the PM or stakeholders: this is what the book will explain.
About the Authors
Before discussing this book, I want to share a bit about myself.
Currently, I am a Strong Junior Developer, specializing in developing services using ASP.NET CORE.
I have been working for a year at a certain 'gallery' and I seem to be managing gradually.
I have already read this book twice and highly recommend it to everyone:
- to developers of embedded systems;
- to front-end developers;
- to back-end developers;
- and even to DevOps engineers.
In short, to everyone connected to software development, especially those directly involved in developing various products; I mean, Sales and PMs are not included (although it would also be useful to know why developers sometimes spend twice as much time on a task), I advise reading this book.
And now I will try to argue why I feel this way.
A little about the author of this book (because the authority of the writer plays a significant role for me). I think you will understand me; although it is not always correct, if someone authoritative in the field speaks, you tend to show much more trust in what they say. For example, I believe you are more likely to trust the diagnosis given to you by a doctor rather than someone from the crowd (who just Googled the symptoms).
Robert Martin, also known as Uncle Bob, has been working in programming for various systems (from web services to embedded systems) since 1970. He is a technical consultant and architect, has written for various technical journals, is a very experienced programmer, and a person who played one of the key roles in the creation of the well-known SOLID principles (you could say he is the creator). Additionally, I would like to mention that this book was recommended to me by my team lead, who has over 15 years of experience.
About the Book
Dependencies
Before reading the book, I read several articles on the same topic where the word ‘dependency’ was often mentioned. What does it mean, who is dependent on whom, what exactly does ‘to depend’ mean, and how can a class depend on another?
As I read through the book, I grasped two points:
Dependency is a term meaning that one class (component, service) is aware of another class (component, service), and this knowledge is defined in the code (now Java, C#, and C programmers will understand me) by a specific import of a namespace. In other words: if you have class A with the namespace Default.Classes and class B with Another.Classes. If in the source code of class A, you see 'using Another.Classes;', 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 points from class A towards class B. This means that class B is more independent than class A, and changes in class A will not cause any 'damage' to class B.
SOLID
One of the main reasons I was motivated to read this book was the explanation of the SOLID principles from the original source, as Uncle Bob developed these principles, and you could say that thanks to him, we hear the name SOLID.
For those who are not aware, these principles suggest and advise designing your applications according to 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 of these principles can be applied at the level of classes and objects, at the level of modules and components, and at the level of layers (services).
If you think that the Single Responsibility Principle means that a class or module should only do one thing, you really need to read at least the chapter on SOLID. Because the definition provided above is a consequence, 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 D from SOLID). Throughout the book, I understood that it's not just a principle; it’s also a mechanism and tool through which you can change the direction of your dependencies, making the business logic (DOMAIN) independent of the implementation details of the Data Access Layer (DAL).
Although the principle, like others in SOLID, means something slightly different from a mechanism, this mechanism is used throughout the book and is one of the main methods to invert and change the direction of your dependencies, which is also used in DDD.
On Making Architectural Decisions
The book frequently mentions the principle of making important architectural decisions: what database to use, what framework to choose, which library to include, what to use as a search engine, etc.
So, the author believes that you should make such decisions as LITTLE as possible. Because requirements can change, performance constraints can also change, and the behavioral aspect tends to change. During development, a certain solution may seem less efficient or less convenient than another. The strength of your architecture will determine how quickly and painlessly you can replace one technology with another (by the way, this is exactly what OCP emphasizes).
For example, suddenly, you decide to use MongoDB instead of PostgreSQL, or even flat files, or use mocked data that will be processed in memory. Under certain conditions, this might require rewriting almost all the logic.
To prevent such situations, we can use some mechanisms that will push the decision-making time as far away as possible. One of these mechanisms is abstraction.
References to DDD
DDD — Domain Driven Design — is an approach to developing services with complex business logic that is critical to changes, aimed at maximizing understanding among project stakeholders (PMs, Sales managers, etc.) and regular team members. This means that there should be a ubiquitous language among all project members, allowing everyone to understand each other, and thinking within the same domain with the same business rules.
If you are an advocate of DDD, or want to be one, or don’t understand it but want to, this book is a must-read, especially the second part of the book.
Here the author explains the existence of the Dependency Rule, and why, by following it, you will build the right application architecture. Why dependencies should point towards High Policy components, and why domain (High Policy component) should be independent of infrastructure and how this will simplify your deployment and development.
Abstraction
Uncle Rob also talks about how implementation details can harm your system and prevent it from evolving painlessly in the future.
Remember!
A database is an implementation detail.
Clients (Web, Mobile, etc.) are implementation details.
Frameworks are implementation details.
You need to abstract away from all of this and not depend on it, using the previously described Dependency Inversion with interfaces and abstractions, the Dependency Rule, and other mechanisms.
Methods for building modules
I particularly liked this section, as a developer of services on ASP.NET CORE. It discusses methodologies for constructing a unified service architecture from ready-made components.
Robert described 4 possible schemes for layer separation.
He made it clear why the commonly used three-layer architecture mechanism: UI (controllers), Services (Domain), DAL (Database) is quite poor compared to others. I haven't seen many projects, but in each microservice, for example, on the backend, this three-layer architecture is used.
Similarly, a one-component-one-service architecture is often used. Overall, both are decent, but it has quite a few drawbacks compared to how architecture is built using DDD, especially for services that are critical to change and complex.
In summary, this review of the book has come to an end. I really enjoyed the book and have no regrets about reading it, thank you to the author. To you, dear readers, thank you for your attention, and please don’t judge too harshly — this publication is based on my impressions of the book and my personal enthusiasm.
Source: habr.com
