Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures

by Neal Ford, Mark Richards, Pramod J. Sadalage

There are no easy decisions in software architecture. Instead, there are many hard parts--difficult problems or issues with no best practices--that force you to choose among various compromises. With this book, you'll learn how to think critically about the trade-offs involved with distributed architectures. Architecture veterans and practicing consultants Neal Ford, Mark Richards, Pramod Sadalage, and Zhamak Dehghani discuss strategies for choosing an appropriate architecture. By interweaving a story about a fictional group of technology professionals--the Sysops Squad--they examine everything from how to determine service granularity, manage workflows and orchestration, manage and decouple contracts, and manage distributed transactions to how to optimize operational characteristics, such as scalability, elasticity, and performance. By focusing on commonly asked questions, this book provides techniques to help you discover and weigh the trade-offs as you confront the issues you face as an architect.

Genres: Programming, Technology, Software, Technical, Architecture, Computer Science, Nonfiction

459 pages, Paperback

First published January 1, 2021

About the author

Neal Ford is Software Architect and Meme Wrangler at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery. He is also the designer and developer of applications, instructional materials, magazine articles, courseware, video/DVD presentations, and author and/or editor of 5 books spanning a variety of technologies. He focuses on designing and building of large-scale enterprise applications. He is also an internationally acclaimed speaker, speaking at over 100 developer conferences worldwide, delivering more than 600 talks. Check out his web site at http://www.nealford.com. He welcomes feedback and can be reached at nford@thoughtworks.com.

Reviews

[Sebastian Gebski · Rating 4 out of 5]

I got lured (to read SA:THP) by its title. Or, to be precise, its 2nd part ("The Hard Parts").
I knew who Neal Ford is, but if I recall correctly, I haven't read any of his previous books before.

First of all - this book is mainly about microservices. And coupling. It's tech-agnostic and on a fairly low conceptual level - e.g. in the examples (or rather - on one, huge case study, split among all the chapters to illustrate the corresponding concepts).

What did I like about it?
1. It's near perfection when it comes to illustrating concepts with graphical depictions - it was really a pleasure to read through it just because of that.
2. It has a very sane approach of turning every decision into a trade-off with pros and cons considerations. I know it sounds obvious, but Ford keeps emphasizing that nearly every solution is useful but within a proper context.
3. Yes, the book is about distributed OLTP, but - what was a really nice surprise - there's a dedicated chapter on analytics (building a reporting solution as an extension to the OLTP part).

What didn't I like?
1. The decomposition approach felt "dry" and far from actual domain considerations (how much particular concepts "belong together"). That means that some unfortunate implementation or mistakes in the initial design may get even more solidified (and unquestioned). Even building simple concept maps (with relationships) could help to validate that.
2. I really like chapters 7, 8, 9, ... (even if they didn't bring anything particularly new - they were just very well and clearly written) until unfortunate chapter 12, which was a disaster. The terrible naming (brought out of the blue) and very artificial consideration (asynchronous and strongly consistent, really?) seems like it only brings unnecessary confusion.
3. Chapter 14 (the one about analytics) drifts towards ... the concept of data mesh. Described in a vague and too abstract way - just too far off to be useful :(

In the end, it's really a good book. A good microservices primer. A great repository of knowledge useful for building distributed OLTP systems. But due to those few flaws mentioned, I simply can't rate it more than 4 stars :(

[Amir Sarabadani · Rating 2 out of 5]

The content is quite bad. Reminds me of life gurus but for technology

[Ma · Rating 4 out of 5]

Richards and Ford are known to write high quality books.
If you skip a subtitle, a title "Software Architecture: The Hard Parts" might sound a bit broad for this book.
As some people noted, some parts of the book are somewhat weird (for ex Chapter 12 is wordy and sound artificial, Chapter 14 fails to explain a concept of Data mesh in a clear manner). I would remove 20% of the book as too verbose content.
That said, book is well structured and contains some practical decision patterns on how to architect microservices.

[Ali · Rating 3 out of 5]

Software Architecture the Hard Parts (SAHP) reads like the Phoenix + Unicorn Project for Microservices & Service/Data Mesh. Instead of the DevOps team at Parts Unlimited, SAHP has the Sysops Squad at Penultimate Electronics, a group of architects trying to entangle the legacy ITSM application —mostly Addison and Austen pondering with Logan, later with Dana over Socratic conversations. The resemblance maybe ends there as the decomposition of components in an old monolith towards microservices ends in a quantum entanglement, not joking, just check out second chapter. What could have been simply explained in tradeoff analysis gets quickly into complex taxonomy and didactic descriptions of methods, sneakily marketing ThoughtWorks. Sorry for the cynical take but here is how it goes…

There is a lot to consider in a modular distributed design, say elasticity, scalability, availability, maintainability, connectivity, synchronicity, deployability, maybe even deplorability :) As you try to optimize these for the given case study you’re guided towards microservices which is captured in Architecture Decision Records (ADRs) and can br enforced with Architecture Fitness Functions (AFFs). Most monoliths are big balls of mud, so running JDepend is just the beginning, then immediately comes e=mc^2 like equations, see chapter four for more. All this math must motivate you for formal decomposition rather than tactical forking. If you don’t take the fork in the road :) rather pledge your allegiance to component based decomposition, your work is cut for you: identify your decomposition patterns for each domain and component, capture your analysis and justifications in ADRs and update your automated AFFs to curb your developers’ deviations in the codebase. Don’t forget that “duplication of code is still preferable to coupling”, use some regression analysis to resize your components, when in doubt use orthogonal/operational coupling (sidecars) intended for your destination, you guessed it, to a service mesh.

Following the same domain driven design drills, there is also data decomposition, coincidentally leading you to a data mesh, which is supposed to be less messy, though not really in my experience, still the consensus is, as they put it, “data sovereignty per service is the nirvana state for a distributed architecture”.

This may all sound good theoretically but it evolves fast into loosely/ dynamically coupled independently deployable quanta entangled in at least three dimensions of Consistency (atomic vs eventual), Communication (synchronous vs async) and Coordination (orchestrated vs choreographed). The matrix of patterns (sao, sac, seo, sec, aao, aac, aeo, aec) for architectural tradeoff analysis are elaborated and exemplified in chapter 12 but some combinations don’t make sense, just seem whimsical patterns of sagas. Regardless, designing microservices in the multiverse of heterogeneous platforms and entangled dependencies feels like building Rube Goldberg machines entangled inall these dimensions.

At the end, I can’t help but ask: what is next? A string theory for software architecture?? What is the takeaway from all this if you can’t do data/service mesh? If the answer is, “well it depends!”, what’s all this taxonomy for? These parts are already hard. Can we please stick to old dry principles, eh YAGNI, just KISS?

[Rob · Rating 3 out of 5]

(Note to self: somewhere between “finished” and “abandoned” and “on-going” … an end-to-end/cover-to-cover read through had become an onerous slog, but the chapters and headings are well-labeled, making it easy to look things up as they become relevant and I need to reference the material.)

[Jano Suchal · Rating 4 out of 5]

This is finally a book that talks about what should and should not drive you to break a service into multiple (micro)services. In current world where microservices are hyped as go-to architecture we need to be aware of the drawbacks at least as we are aware of the pros.

Book is well written, however the chapter that talks about exhaustively about various combinations of coupling etc was a bit tedious to read with less added value (the book would be good or even better without it). Overall a great read, recommended.

[Denis Romanovsky · Rating 5 out of 5]

A big book, lots of topics covered quite well and with examples. The text is clear and easy to comprehend. Modern approach to architecture of distributed systems with all fresh knowledge available to the date, trade-off analysis at its best, microservices in a reasonable way, even data mesh part was understandable. Recommended!

[Дмитрий Филоненко · Rating 5 out of 5]

No evangelism like in those "5 min to read" posts on Medium or Reddit. No yet another holywar Monolith vs. Microservices. This is a book about analysis, about thorough scrutiny of trade-offs. The authors repeat through all the book: there is no silver bullet, and there is no solution that should always be preferred. There are as many architectures as software products, and all are different. What works in one architecture would not work in another.

The authors take every aspect of software architecture - data ownership, transactions, data access, workflows, contracts, reuse of code, granularity of services, etc - and analyse known patterns for each of the topics and the trade-offs inseparable from those patterns: synchronous vs asynchronous, atomic vs eventual consistency, orchestrated vs choreography, better control vs scalability, responsiveness, fault tolerance, coupling, throughput, security, error handling, you name it. Every problem offers a few solutions, or a few architectural patterns. And every pattern has its strong sides and weak sides. Hence the job of an architect is to know what business needs, which problem it wants to solve, so then she/he can infer what should be prioritised in a solution architecture and what can be sacrificed. Clarity about needs and priorities will lead to a choice of a specific pattern. And sacrifices are inevitable.

[Oleksandr Stefanovskyi · Rating 4 out of 5]

I read this one with a group of senior software engineers, and we all enjoyed it. The book's structured approach and those "discussion dialogs" really helped make the trade-offs in distributed architecture feel real and relatable. It’s practical, well-organized, and gives you a good sense of what it's like to face these decisions in the wild. Definitely worth a read for anyone digging deeper into software architecture.

[Sumant · Rating 5 out of 5]

What an fantastic book to start my year with, I heard about this book on twitter, where I follow https://twitter.com/deararchitects handle, and got curious about this book, as many people whom I follow were recommending this book.

Now this book is not at all cheap in India, and although I had an option of getting this on my kindle, but I like to read technical books with paper in my hand, as it gives me an option to use plain old paper and pencil to jot down my thoughts about the topic. I purchased this book for 1400/- Rs on amazon, and tell the fact I don't regret it at all, and actually I am planning to purchase more technical books from Oreilly in the coming future.

Getting back to what this book is about, it basically trains you to see everything as a trade off in software architecture. Nowadays the software industry goes on working on buzz words, and since last few years this buzzword is Micro services.

But are Micro services the correct solution for you ? and if you finally decide to walk down the difficult path of Micro services, this book will definitely you in that journey, because Micro services are not all easy, and they are also not silver bullet which some claim they are, it takes a lot of effort, thinking and work to get Micro services right, because if you search on the web you always get either two opinions about Micro services, some say they are bad and some say they are good.

But if you want to actually understand Micro services architecture, and how to go about implementing them, with involvement of your stakeholders, this book will teach you that. Because every thin in any architecture is always an trade off, you have to actually create a list of pros and cons of the decision you are making, and whatever decision you take has to be then documented and then only you should implement it, also communication with your stakeholders is very important because at the end of the day, those guys will ultimately give you the money for resources.

The authors of the book have done an fantastic deep dive into each of the nuances of an micro service architecture be that be how do you communicate between services, or how do micro services actually save data, should they save data in their own database, or should you have an centralized database, is having a centralized database actually a micro service, this and a lot more has been covered in this book.

It's like after reading this book you actually become a good developer and an informed Architect, because you come to understand how to weigh the pros and cons while taking any decision, and not follow any advice blindly.

An highly recommended book with 5/5 stars.

[Edmund · Rating 4 out of 5]

A solid book overall which discusses some of the trade-offs in modern software architecture. A lot of the focus is on how you would go about decomposing an existing monolithic architecture, which is probably the situation faced by the majority of the readers. As such it won't be as a compelling read for those who are already working in the SOA/Micro-services space. At times the author is rather verbose making the book a rather long read.

[Scott Pearson · Rating 4 out of 5]

A software architect foresees potential issues in a design and judges which way will instill the most business success in the long run. Unfortunately, in almost every scenario, trade offs permeate every option. As the saying goes, the devil is in the details. Learning to anticipate problems with wisdom set great software architects apart from merely experienced ones. In this book, several experienced authors look at those trade offs in the context of distributed software systems that are so fashionable these days.

Distributed systems and microservices are used in large systems that integrate for innovative results. When the computing is parsed, each system becomes its own special service, and breaking up the systems with minimal “coupling” between them becomes a challenge. In addition, businesses inevitably need to see the big picture of their work. Integrating the distributed system must happen, but no perfect way exists to implement integration. These sort of challenges require the careful wisdom this work offers.

This book is extremely abstract because software architecture is abstract by its nature. It covers some of the most challenging topics in distributed systems. I chose to listen to an audiobook format and somewhat regret the choice. Instead, I would have preferred to read the book in print for several reasons. First, tables would be easier to parse. Second, some sections are lists of different combinations, and listening to these was extremely boring. Finally, the text is so abstract that I would have liked to hover my eyes over a word or look up past definitions. None of these are facilitated by an audiobook format, unfortunately.

The content itself is good, but it only addresses a niche audience. I’ve never designed a distributed system from scratch, so this text helped me think through potential pitfalls. Via these principles, I mentally redesigned some of the smaller systems I work with so that I could see what a more distributed system might look like if we ever have to go that route. This book is not an introduction to software architecture but meant for more advanced practitioners. Still, the careful thought dwelling in these pages can prevent shortsighted mistakes, cut lost employee effort, and lessen company expenses.

[Meysam · Rating 5 out of 5]

This is one of the best books I've read on software architectures so far.

It's a collection of cohesive architecture topics with no-BS content that will deliver real insight and does not beat around the bush. Many similar works are usually repetitive and only discuss the surface of what everyone else is and already has talked about. Not this one, though! It is genuinely insightful and full of takeaways for aspiring (to-be) software architects.

From a thousand viewpoints, the main insight is that software architecture is a trade-off of many forces; some and not all will be non-technical and business-related. The architect's role is to avoid evangelism because there is no silver bullet in architecture, but there is always a trade-off. On that matter, "never say never, unless you're talking about never"!

In fact, an organization's architect will serve its purpose best by not mindlessly following trends and technologies, as that is best left for tech leads and developers, but rather understanding the upside and downside of each decision and each integration.

Remember, if an architect sees no trade-off (and downside), it only indicates that the architect has not looked hard and deep enough! Cause there always is one.

This book is highly recommended for all current and future architects. They will be greatly served if they do not skim the book but rather take time to fully understand what the authors are trying to say. Huge shoutout to the authors for sharing their lifelong insights with the rest of us.

[Vicki · Rating 3 out of 5]

Admittedly I didn’t do this book justice, concentrating on the first four chapters and then skimming the rest, but I found the idea that there should be a book separate for software architects which gives advice without regard to software engineers kind of funny. Like, I know extremely large companies have people whose job is to do only architecture but then I don’t understand how you have skin in the game of the system you’re building.

[Geoff · Rating 4 out of 5]

Great level of detail

I wish I had this book 10 years ago. Now it is a good way to ramp up quickly on the complexity and tradeoffs in modern architecture

[Marcin Kuthan · Rating 4 out of 5]

Well written book with the story behind. The story about migration from monolith to microservices. I really like ADRs, and strong focus on trade-offs everywhere. Atomicity vs. eventual consistency, synchronous vs. asynchronous, orchestration vs. choreography. Worth reading even if you are in microservices world to avoid drift to monolith antipatterns. I only miss more details about data mesh, e.g fitness functions for data quality.

[Ivan Chernov · Rating 3 out of 5]

Зря так долго читал. Первая половина книга - прикладной пример как распиливать монолит, вторую половины книги после саг лучше не читать.

[Andrei ILchenko · Rating 5 out of 5]

The book is an excellent follow-up on the earlier “Fundamentals of Software Architecture” by two of the same authors — Mark Richards and Neal Ford. In this book they zoom in on Service-Based and Microservices architecture styles and show how an imaginary company (selling consumer electronics and providing support for sold devices) rearchitects its Sysop Squad application from a monolith into a Microservices-based distributed architecture.

The main value of the book is in showing how to rearchitect a monolithic application into a distributed one based on either a service-based or a microservices architecture, taking a systemic approach to this feat. The starting point is the concept of an architectural quantum — a collection of software components and databases/middleware they use that is characterised by:
* a need to be deployed together
* high functional cohesion
* high static coupling
The goal of migrating from a monolithic architecture where there’s just one architectural quantum to a distributed one where there are many quanta is to ensure improved maintainability, changeability, scalability and availability. Throughout the book the authors promote the use of domain-driven design principles and eschew technical partitioning in architecture in favour of domain partitioning. Another recurring theme in the book is the first law of software architecture that everything in software architecture is a trade-off. They go to great lengths to do this trade-off analysis for everything they delineate in the book.

The first step of the journey is to determine if a monolithic codebase is decomposable to begin with. The authors recommend to decide on it based on the measures of the codebase’s abstractness (the ratio of the number of interfaces and abstract classes to all interfaces and classes) and instability (the ratio of outgoing, aka, efferent calls to a sum of incoming and outgoing). Adhering to the main principles of proper software design such as those promulgated by the Design Patterns should make this possible. Not doing it can easily result in the monolithic application being a big ball of mud that is beyond the state of repair and where the best solution might be its _tactical forking_ into multiple applications with lots of code duplication among them. For better designed monolithic applications the best approach to turning them into a distributed architecture is one based on _component-based decomposition_, which is the approach the authors pursue in the book. The outcome of component-based decomposition will be a better structured codebase encompassing the principles of Domain-Driven design and a set of components that can be turned into services.

The second step is to determine how to translate candidate components into services, e.g. one-to-one or, sometimes, many-to-one where a few components will become one service. The main rules to use are those of granularity disintegrations (forces supporting each component to be an independent service such as different scalability needs or different change frequency) and granularity integrators (forces pulling in the direction of multiple components being one service, e.g. a need for automic database transactions among these components, important data relationships to be enforced by the database, easier workflow and choreography to support use cases spanning these components). The second step should be done taking database tables into account as well. In fact the authors do an excellent job of explaining the need to align data domains with software domains when domain-partitioning codebases. As a minimum a datadomain should not span more than one database schema, ideally it should be an independent database. This is also the reason why each microservice should fully own the datadomain it needs to store its data in (with a rare exception of a shared data domain ownership where its impractical to break tables apart or for other reasons). Datadomain ownership is based on which service can write to the tables in the datadomain, ability to read doesn’t not imply ownership.

In the second half of the book the authors analyze dynamic coupling among services as they jointly implement a workflow, which they eloquently express with 1) the following mutually exclusive criteria:
* communication (synchronous or asynchronous)
* coordination of workflows (mediation/orchestration or choreography)
* consistency (atomic or eventual)
and, 2) whether contracts between services are strict or loose.

They dedicate a whole chapter to how a workflow among services can be implemented using one of the 8 possible combinations of communication, coordination and consistency. They call each combination of these three in handling a workflow a _Transactional Saga_. E.g. synchronous communication with an orchestrator and atomic consistency is an Epic Saga, while one where choreography is used for coordination is a Phone tag saga, both constitute an attempt to mimic the behaviour of components in a monolithic architecture, with all the inherent disadvantages thereof such as poor scalability. Surprisingly the authors didn’t propose the use of XA transactions to achieve automicity, which might be a more elegant way to obtain it than the use of compensating updates for error handling which the authors suggest. Other interesting transactional sagas rely on eventual consistency — the fairytale saga, parallel saga and anthology saga. The way you handle error conditions in these is by maintaining a saga state machine in the orchestrator or by using _Stamp Coupling_ in choreographed workflows.

Finally the authors explain the differences among Data Warehouses, Data Lakes, and Data Meshes when it comes to organising data for analytics and ML purposes. I found their explanation of the rationale behind the concept of a data mesh—ownership of analytics data must stay in the same domain as one responsible for the operational data domain and the services using it—quite intuitive to grasp.

I hesitated whether to give the book 4 or 5 starts due to a somewhat drawn-out style of presenting information in the second half of the book and my tiredness with the contrived dialogues among the architects of the imaginary Sysop Squad application. At the end I felt that 5 starts would be a fairer assessment as one can easily skim the monotonous parts.

[Ahmed Taha · Rating 5 out of 5]

Hats off to Neal Ford, Mark Richards, Pramod Sadalage, and Zhamak Dehghani. Yet another brilliant software architecture book with focus on some of the most challenging decisions & trade offs in today's modern, distributed software architectures.

I truly enjoyed the storyline of the fictious organization which not only did it bring the key concepts to life, but it also touched on the typical communication challenges found in organizations.

I am going to borrow a sentence from the book to describe it: "This book is a treasure trove of good information".

Highly recommended read!

[Christoph Kappel · Rating 5 out of 5]

This book demonstrates how decisions in architecture should be made - if at all. Chapters usually start with some kind of scenario and a given problem. Then different solutions to the problem are presented, followed by details about the trade-offs. And when the decision has been made it is documented in an ADR.

Besides that, it contains the usual things you can find in a book about architecture like microservices yes/no, big ball of mud yes/no and so on.

[Jevgenij · Rating 5 out of 5]

There are many good things about this book:
- reasoning behind suggested solutions
- wide range of presented architectural decisions
- "real-life" examples

The only drawback I found was that certain solutions (e.g. Data Mesh) were presented very poorly. If you are not familiar with them, additional sources will be required.

[Michal · Rating 3 out of 5]

It is a fair book about when, why, and how to split big services into bearable but not micro chunks. It all makes sense and could be a great book for me to read many years ago. Unfortunately, I'm afraid that it wouldn't serve that well, because sometimes I understood what is written only thanks to my experience. Explanation is tedious yet it doesn't make it clearer.

[Michał Sitko · Rating 2 out of 5]

I bought this book based on recommendations on some forum, so I skipped the usual pre-purchase due dilligence. I expected broad (i.e., not related to a particular technology) and non-obvious insights. I ended up deeply disappointed.

The book is mostly about microservices. If you spent a few years developing in such environments, you probably know most of the topics. Or rather, you used most of the described techniques, picked between them based on circumstances, but you may not know the fancy names authors gave them. Did you know that every time you try to split an unstructured blob of code into well-defined components you are applying Component-Based Decomposition pattern? After reading this book, you will know that.

One may say that there's a value in establishing a common vocabulary. Agreed, yet with a caveat that introduced terms must describe succinctly something otherwise tricky or wordy to explain. Few of introduced terms meet this criteria, though. Your services either share the database or use separate ones; naming it Join Ownership, or anything else, only obscures that.

That's the biggest problem with this book - it's wordy, introduces concepts you already know, create taxonomies of them that do not lead to any insights, while not going into nuances too much. So, in the end, contrary to the book's title, it's quite introductory.

And what if introductory is what you need? The book invokes some DDD concepts, scratch a few surfaces on distributed systems, databases and versioning. It does not introduce Bounded Context while referring to it quite a lot. So if you're looking for more basic content, you'd better reach to canonical resources on each of topics. For example, Evans / Wlashin on DDD, Kleppmann on all things distributed, and so on.

The other big issue I take with this book is the implied, yet very strong, distinction between code and architecture. It's never stated, but the whole book is written with the assumption that there is a bunch of architects discussing charts and topologies in their ivory tower, and there's some code somewhere else.

Such distinction feels very foreign to me, and I cannot imagine how it can lead to good outcomes. It's also something against my vision of what Software Engineering should be about. There are plenty of books that do not give that "compartmentalized vibe", for example "Software Engineering at Google".

Regarding fictional narrative interwoven into the book - I like the idea itself. It provides an opportunity to anticipate various counter-arguments, as well as the team dynamics around such discussions. It's a risky choice as authors are software professionals rather than novelists, but in the end, I don't mind it as I am not here for literary value anyway.

It's something else that really bugged me in those fictional dialogues. It's the overemotional, unprofessional, and borderline aggressive attitude of some characters involved. To give you a sense of it: "That's the worst idea I've ever heard, said Taylen, everyone knows you should...".

I don't know if it's supposed to be a realistic depiction (fortunately, I didn't have to deal with such an attitude yet), something advised, or a dramatic exaggeration to keep me focused. None of those make me appreciate it.

All in all, I regret I bought this book, and ended up skimming significant parts of it. 2 stars as it's edited well, and it delivers a few interesting insights. In general, the book doesn't feel sloppy in any aspect, I just don't buy the main premise, plus the interesting bits are presented much better, and from first principles in other sources. For me, this book could have been 3 blog posts.

[Sergiyb · Rating 4 out of 5]

Quite a good book about software architecture (SA). Frankly, it is my first book about SA, so time to time it wasn't an easy to fully understand it. I assume it is better to read previous book: Fundamentals of Software Architecture: An Engineering Approach
In this book described creating sets of microservices from monolith. And it was shown for fictional `SysOps Squad`.
Short summary: I recommend to read this book.
And it would be quite interesting to check how GmCore made their monolith break and how it correlate with what was described in this book - for me, guys from `SysOps squad ` solve similar problem
New terms/notions I found in this book:
1) Fitness functions
2) Architectural decision records
3) Several architectural attributes (elasticity, scalability)
4) Big ball of Mud (I didn't know this term before)
5) Where and why use various approaches common logic for various microservices (even copypast can be a solution - WET vs. DRY)
6) BASE vs ACID
7) Some db types (Column Family Databases, NewSQL Databases, )
8) Architecture Quantum (look like new term made by authors)
9) Orchestration vs. Choreography, Eventual consistency vs. atomic consistency, async vs. sync communication

What I didn't fully understand:
1) Service mesh (and DB part of it)
2) Probably something else, what I think I understand, but not

Not fully agree:
1) That all code should be only in `leaves` folders
2) Afferent and efferent connections and abstractness (abstract/implementation) and instability (efferent/(efferent + afferent))

[Anton Antonov · Rating 5 out of 5]

Another good Neal Ford book. I recently re-read it to compare and help others start walking the adventurous path toward software architecture. Is this one or "Fundamentals of Software Architecture: An Engineering Approach" better for newcomers? 😉

As the authors themselves write, "When two of your authors, Neal and Mark, were writing the book Fundamentals of Software Architecture, we kept coming across complex architectural examples that we wanted to cover, but that were too difficult. Each one offered no easy solutions but rather a collection of messy trade-offs. We set those examples into "The Hard Parts.". 🤔

And here we are. I'm reviewing my notes and recordings from the Mark Richards and Neal Ford workshop(s) I attended a few years ago. These workshops explored the trade-offs between distributed architectures. I see the same information passed down here in a much more polished format. 🙏

It's an excellent follow-up for people who are starting to explore software architecture. It's not an easy path, but with the Fundamentals and Hard Parts books, you're guided through the risk questions: What is Software Architecture? Where does DDD fit into that? Does it? What is risk? And yes, risk. I always talk about risk, and "Thinking in Bets" is another excellent book. Yes, I wrote about it. I highly recommend also reading it for the betterment of your personal life!

As always, with such books, there's not a single read-and-forget. Or, hopefully, read and remember it all. This book, along with hopefully many others, will be your go-to reference for many years when tackling new problems, revisiting old ones, and finding creative inspiration. It's a good book to have at your disposal, providing long-term value. 🤝

[Rebecca · Rating 1 out of 5]

Software Architecture: The Hard Parts - or rather, The Parts that Did Not Need to be Hard but Were Made So Using Unnecessary Definitions and Unrealistic Examples.

Honestly, what a total waste of space. This is supposed to be a "next level" book, but it just covers some basic break-the-monolith strategies (with focus on a horrendous approach which creates database-level dependencies between services). It takes an ivory tower perspective, where it's suggested that architects can make all their decisions based on repository statistics and can control their teams using "fitness functions" to spy on them. All of it is packaged in a super cringe, contrived story of a company-wide overhaul where for any question, you go to a guy named Logan who tells you that everything is a tradeoff between very obvious, or sometimes just incorrect, factors.

Except for Data Mesh. This is the silver bullet that works in any organization.

Honestly, it baffles me that something like this can get published? Endorsed? Can they not see that their definition of architectural quantum is a) completely uninteresting for actual system coupling, and b) immediately leads to that basically all systems are just one big quantum? Why are multiple services allowed to connect to the same DB even in the final target architecture? Why do they use examples that are so silly, like suggesting that a signup procedure and a credit card verification should definitely be done in one atomic step? This is just ridiculous.

If you do have to read this book, please do so with a group of people, so you can help each other recover from the gaslighting this book will subject you to.

[Andrey · Rating 5 out of 5]

Context: I have no relation to software development. I work more with hardware infrastructure. First, I read the book to increase my awareness because "every company is now a software company." Secondly, to sneak a peek at some practices for organizing system architecture because software development is now the most advanced domain, constantly trying something new. And not just systems but, according to Conway's Law, development teams as well.
For my purposes, the book proved to be more than exciting and valuable, especially since I read it as a continuation of a series of books on software architecture, in which Neal Ford was among the authors. Here is one of the book concluding phrases: does it not apply to all teams, not just developers?

“Discipline. <...> We continue our new habit of creating trade-off tables for all our decisions, continue documenting and communicating our decisions through architecture decision records, and continue collaborating with other teams on problems and solutions.”

[Rauno Villberg · Rating 5 out of 5]

tl;dr: "it depends"
But no, for real, unfortunately there's always trade-offs and there are no silver bullets. This book provides great guidance on how to analyze these trade-offs with some very insightful thoughts (for example, that "semantic coupling" can never be reduced by architectural choices, but can certainly be increased by them)

Speaking as mostly a mobile app developer: quite a lot of the stuff in this book is not directly applicable to my day-to-day, but I still found it very interesting and I'm trying to judge it more from the perspective of the kind of person that's more specifically in the target audience.

It's not the easiest of reads if you're already tired from a day of software engineering - technical details to ponder - but the way it's set up to have this reoccurring realistic-sounding story throughout of a team of engineers trying to decide between different architectural approaches makes it captivating and helps the book not feel like just "dry advice", but actual, practical, experience-based information.

[Ahmad hosseini · Rating 4 out of 5]

This book is primarily about decision making, enabling architects to make better decisions when confronted with novel situations. This book will equip you with the theoretical background and with a practical framework to help answer the most difficult questions faced in modern software architecture. It doesn’t focus on technology or other implementation details. Rather, It focuses on how architects make decisions, and how to objectively weigh trade-offs when presented with novel situations.
The Hard Parts provides the reader with valuable insight, practices, and real-world examples on pulling apart highly coupled systems and building them back up again.
I think these three facts about the book will convince you to read it!
1- The book authors
2 -There is a complete example of converting a monolith application to microservice.
3- Book also examines different saga patterns and their trade-offs.

[Artem · Rating 4 out of 5]

It took me a while to finish this book. It was a hard but useful read. I have already had chance to apply this knowledge in practice.
What I liked about this book?
All terms are well-defined, narrative builds on top of earlier defined concepts. Patterns supported with trade-offs and examples.
I learned a more systematic way to approach tradeoff analysis.
What made it hard to read?
Despite the effort to connect the theoretical part with fiction story, which reads a bit naive, it is harder to comprehend abstract concepts disconnected from actual for you problems.
I think this book can be used for two purposes: developing mindset of tradeoff analysis, and as a reference at later time when you encounter problem similar to what was discussed in the book.