Fundamentals of Software Architecture: An Engineering Approach
An Engineering Approach
Mark Richards & Neal Ford
This book provides the first comprehensive overview of software architecture’s many aspects. Aspiring and existing architects alike will examine architectural characteristics, architectural patterns, component determination, diagramming and presenting architecture, evolutionary architecture, and many other topics.
Over the past few years, I have noticed that as a software developer more and more of my time is taken up by architecture discussions. Whether it be discussing or defining how to develop scalable applications or the merits of microservices architecture or even just deciding how to structure files and folders in a software application. Software Architecture has become such an intrinsic feature of software development.
Over the past few months I have also been reading a lot books discussing various aspects of Microservices and pros and cons of each approach, especially how to migrate from monoliths to microservices . Many of the books I’ve been reading discuss some of the basics of the various architecture patterns but never really discuss them in depth, therefore I was looking for a book that dives a little deeper into the various patterns. I didn’t want to go too in depth, as lets be honest it takes a lot of hard reading and dedication to read these books cover to cover.
Why I read this book
Over the past few months I have been particularly enjoying o’Reilly books in general, and have found them on the whole to well written, edited and thought through. From my perspective the authors seem to be well briefed and directed on what needs to be delivered. I have been finding the books to deliver on what was promised. This book, was recommended as a next purchase and from the title it appeared to be exactly what I was looking for.
What I like about this book
I found the book to provide an excellent overview of the various architecture styles providing clear rationale behind the decisions made by each of them and why they are better in certain contexts.
I particularly enjoyed the chapters on Modularity, because it focused on the engineering aspects like cohesion, coupling or connascence and I also discovered there were ways to measure these aspects.
Chapter 4, architecture characteristics defined, was really illuminating for me personally.
I felt chapter 6, was a great companion read for A philosophy of software design as discusses cyclomatic complexity and why it is important for architects and software teams to keep a watchful on it. This is something, I have been very acutely aware of in my time as a software developer and I’m glad this book discusses it from an architectural perspective.
The section on the soft skills required as an architect is great and reminded me of Soft Skills by Jon Sonmez . , this books provides some good tips Time Management, creating presentations, relationships with teams and many more.
What I learned from this book
Architecture is the stuff you can’t Google.Fundamentals of software architecture
Everything in software architecture has a trade-off: an advantage and disadvantage. Thinking like an architect is analysing these trade-offs, then asking “which is more important: extensibility or security?” The decision between different solutions will always depend on the business drivers, environment, and a host of other factors.
Thinking like an architect is understanding the business drivers that are required for the success of the system and translating those requirements into architecture characteristics. In my opinion and from the perspective I approached this book, does a good job explaining the different architecture approaches with pros and cons of each.
Why I recommend this book
I feel this is a good book for any aspiring or already software architect, because it provides clear explanation on various existing types of architectures, also some good insights and ideas on how to evolve into a better software architect and team player. I would recommend all developers to read this book too because we do tend to worry too much about code in general and not enough about the business problems we’re actually solving.