5 Books Every Aspiring IT Architect Should Read
Architects are different – and so is literature for them
Let's start with the fact that architects can be completely different. For example, some form business processes, work with TOGAF and other patterns. These guys are more immersed in operational processes than in technical ones.
And there is a solution-level architecture. This is when the architect, together with the team, can sketch out a general plan and summarize whether it corresponds to the company's concept and does not contradict the requirements of a higher-level architect. Such an architect distributes interaction between all teams, while maintaining the basic principles.
There are also system architects, infrastructure architects, and so on. They are all responsible for specific areas.
Each has its own specifics, so recommending books for all architects in general is not entirely correct. But I have a selection of five books that will suit those who want to grow in IT architecture – the very basics of the basics. In practice, of course, you will have to read much more.
5 Books for Beginning Architects
And here is my “basic” selection:
“Object-Oriented Design Patterns” by Ralph Johnson, John Vlissides, Richard Helm, Erich Gamma.
“Microservices: Design and Refactoring Patterns” by Chris Richardson.
“Python Development Patterns: TDD, DDD, and Event-Driven Architecture” by Harry Percival and Bob Gregory.
Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture, Tomasz Jaskula.
Cloud Native Microservices With Kubernetes: A Comprehensive Guide to Building, Scaling, Deploying, Observing, and Managing Highly-Available Microservices in Kubernetes, Aymen El Amri.
Next I'll tell you why I like each of them.
“Object-Oriented Design Patterns” by R. Johnson, J. Vlissides, R. Helm, E. Gamma
And here's some good news: there's good translation. And I'll warn you right away: the book gives examples of C++ code, and this can be scary. I advise you not to give in to the urge to put it aside until better times, because the guys explain everything quite simply and the text is basically aimed at understanding.
More than 20 years have passed since the first edition was published, and during this time the book has become a cult classic. It describes object-oriented programming patterns for working with monolithic solutions and OA servers. They were invented a long time ago, and you can’t go anywhere without them. It’s important to understand how and why it all works.
The book will help you understand the role of patterns in the architecture of complex systems, and also create your own applications taking into account the limitations that arise when developing large projects. The patterns in the book are taken from real systems and are based on real cases.
If you are more focused on monolithic work, which means you have to monitor the decisions inside the code, I definitely recommend this book. In essence, this is system architecture.
“Microservices: Design and Refactoring Patterns” by Chris Richardson
IN book describes 44 patterns of designing microservice applications. It will help you understand why you should use a microservice architecture at all, how to decompose a task for a microservice, what size it should be, and so on. It also covers transaction management and request patterns, testing strategies, and deployment patterns.
Excerpts from this book are already circulating on Russian-language forums. Enthusiasts have created their own collections: 30 patterns, 40 patterns, and so on. But I recommend the original source.
By promo code IDKFA in Stroki these books can be read for free. Activate the promo code – until 30.09.2024.
“Python Development Patterns: TDD, DDD, and Event-Driven Architecture” by Harry Percival and Bob Gregory
Theory is cool and great, but a good architect should try out his knowledge in practice and delve deeper into the work process. This book allows you to get acquainted with TDD, DDD approaches. All this is described in the book – you can try out patterns and understand from personal experience how comfortable you are with them.
The authors write about:
“dependency inversion” and its relationship with ports and adapters,
about patterns and the differences between them – for example, what is the difference between the Entity, Object-Value, and Aggregate patterns;
division of responsibility into teams and requests;
event-driven architecture and reactive extensions.
I would like to point out that the book has many good examples in Python. I used them myself and I recommend you do the same.
Strategic Monoliths and Microservices: Driving Innovation Using Purposeful Architecture, Tomasz Jaskula
Many people, upon hearing “microservices,” immediately say: “A monolith sucks.” But that’s not true, all solutions are good in their own way.
To really understand this, to get to the bottom of it and to justify your decisions, it is useful to read this book. It is written in English, I have not yet come across a translation. But the guys write easily and talk about the topic very well – it was interesting to read.
Cloud Native Microservices With Kubernetes, Aymen El Amri
Finally, one of the top books on the infrastructure part of system design. Full title: Cloud Native Microservices With Kubernetes: A Comprehensive Guide to Building, Scaling, Deploying, Observing, and Managing Highly-Available Microservices in Kubernetes.
As architects, we must understand how an application works at the infrastructure level, what CI/CD is, high-level capability, GitOps, etc. This is discussed in detail in the book. Modern key stories are described in detail: clinative, cubic architecture, QR components.
I recommend this book to anyone who truly wants to be a multidisciplinary architect.
Why read at all?
Being an architect is a constant learning process. Almost like being a programmer. For example, a programmer has learned C++, but there are far fewer innovative changes in it than in approaches to developing patterns, frameworks, technologies, and so on.
An architect is a person who must be on trend in everything and always. In order to understand modern solutions and figure them out, he must constantly learn. It is important for him to navigate in the choice of technologies, approaches, patterns, frameworks – all this can greatly affect the company's processes, the product.
An architect's job is not only to design a cool system. It also needs to be defended to the Tech Lead developers who will then implement it. For example, I once showed the architecture to a new team and they said, “Oh, come on, your architecture doesn't suit us. We've always worked with monoliths.” And then I had to convincingly prove to the developers why they should use my architecture. I read a lot on this (and other) topics — for example, the same Strategic Monoliths and Microservices. So it was easy for me to explain why a monolith would turn into a problem in five years — even if the developers don't think about it at all now. An architect should always think conceptually and ahead. By the way, I still managed to convince the developers.
But to sell the architecture to developers, you first need to sell it to yourself. That is, you first need to convince yourself that your solution is high-quality and necessary. And it is much easier to do this, again, if you have a broad outlook, you can evaluate the situation from different angles and can make forecasts. Books, of course, are very helpful in this.
Now it's up to you! Tell us in the comments what books you've already read and how it went. I'm currently thinking about a selection for experienced IT architects, so we'll continue the topic soon.
