Software Architecture: The Hard Parts — Episode 1

The book grew out of Fundamentals of Software Architecture: Ford and Richards kept putting aside hard questions that did not fit there and invited two data-focused co-authors; the club recently added Dehghani's data mesh article to its architecture newsletter and discussed data mesh with Vlad Khononov two weeks earlier. Alexander shows how the authors justify the title: "hard" has two connotations — difficult decisions, and the fundamental, what is hard to change later; architecture answers "what", design answers "how", and design is left out of scope. The first chapter references other books generously, introduces two kinds of data — operational, without which the business does not run, and analytical — and reminds that data outlives systems. Vova adds from the conversation with Vlad: where data is critical, event sourcing with a single source of truth helps. Ilya explains ADRs — a record of a decision with its context, reasons, and consequences, which the club itself uses for large changes; Alexander recommends the second edition of the book by the ADR author, where architecture is examined from the operations side.

Once an ADR is agreed, you need to check that nothing falls apart — hence fitness functions: any mechanism that gives an objective assessment of one or several architecture characteristics, such as JDepend and ArchUnit for finding cyclic dependencies. Alexander recalls Building Evolutionary Architectures from 2017, where anything tested was called a fitness function, and warns: easy to talk about, hard to do — anything beyond cycles and cyclomatic complexity, like Uncle Bob's coupling assessment, cannot be fully automated, someone has to read the result. At a conference he showed a team that moved such checks onto Elixir with its well-described syntax, and promises a link. A useful heuristic from the book: if the function needs domain knowledge, it is an integration test, not a fitness function. Ilya notes that linked characteristics — security and performance — are balanced rather than optimised separately, and Alexander sees the point of holistic functions in that: fix the trade-off and watch that nothing tips over. The chain "non-functional requirements → quality attributes → architecture characteristics" is really a way of selling to the business: characteristics that affect time to market sell better than requirements with a negation in their name.

The book's running example is the Sysops Squad saga: a support-service monolith that the business threatens to shut down over missed deadlines and lost data, with notes in which architects discuss decisions. Ilya finds it unreal — too bad a monolith and a business that accepts everything without objection; Vova adds that the architect is the book's hero and saviour, like the engineer in The Phoenix Project and its sequel. Chapter two opens part one — analysis, splitting into pieces — and introduces the architecture quantum: an independently deployable artefact with high functional cohesion, high static coupling, and synchronous dynamic coupling. Examples: a monolith together with its database is one quantum, because it does not start without it; a service-based architecture around a shared database is also one quantum, and a migration breaks the forgotten fourth service; an event-driven architecture with a shared database likewise; solid lines on diagrams mean synchronous calls, dashed ones asynchronous, so queues need not be drawn. Microservices are a quantum each, but a shared user interface glues them back, and the authors bring up micro frontends; a database shared between systems glues even independent services together.

Before the stream Ilya and Alexander argued about why the definition does not fully work: if services depend on a Kafka cluster and do not start without a connection, do they fall into one quantum? Ilya believes retries, idempotency, and fallbacks reduce coupling and let the quanta be separated; Alexander clarifies the authors' definition: an interaction is synchronous when the caller stops and waits for a reply, and if a service cannot work without receiving data, that is synchrony regardless of transport — Kafka with a wait for the reply will not deliver the characteristics of asynchrony. He shows his diagram of the chapter: the quantum breaks into four parts, and dynamic coupling into three dimensions — communication style, consistency, and coordination, orchestration or choreography — and brings up the authors' three-dimensional table with amusing names for the eight combinations. Ilya notes the parallel between the quantum and DDD's bounded context: the quantum went further by adding static and dynamic coupling, but the original correspondence shows through.

Chapter three opens with the right question: the architects in the story want to split the monolith because nothing else helped, and they are sent back — explain why first. Business drivers are time to market and competitive advantage, mergers and acquisitions, new markets; Alexander expands: an established company is always surrounded by startups with more convenient scenarios, and slow change leaves you in the place of the dinosaur that realises a minute later it is being eaten. From speed follow availability and fault tolerance, and from unpredictable load, scalability. Technical drivers: maintainability through coupling, cyclomatic complexity, component size, and partitioning by domain rather than technical layers; testability — automation and coverage of the scenarios; deployability; scalability, which the authors distinguish from elasticity: the first is like climate with steadily growing users, the second like weather with daily peaks and a popular band's concert, and for it the application must start fast; and fault tolerance.

The examples go characteristic by characteristic. Maintainability: in a layered monolith a feature touches the UI, the backend, and the database and needs three teams; partitioning by domain touches less, and in microservices one team owns the function, although the UI and micro frontends may still make it two. Testability: a change in one service looks local, but dynamic links A → B → C force the whole chain to be checked, whereas an isolated module lets you run a small test set instead of a gigantic one. Deployability: deploying one service out of a quantum with dozens of services risks a chain reaction, because a monolith has no explicit contracts, and code freezes appear. Fault tolerance: the larger the quantum, the larger the failure domain — Vova compares it to the blast radius; a load balancer with two monolith instances does not save you, because the bug in one instance knocks out the second, as in a game of elimination. Next episode — architectural decomposition and component-based decomposition, where the story's first ADR appears.