Software Architecture: The Hard Parts

The authors built many distributed systems a few decades ago when they first became popular, yet decision making in modern microservices seems more difficult, and we wanted to figure out why. We eventually realized that, back in the early days of distributed architecture, we mostly still persisted data in a single relational database. However, in m

static coupling analyzes operational dependencies, and dynamic coupling analyzes communication dependencies.

An easy way to think about the difference is that static coupling describes how services are wired together, whereas dynamic coupling describes how services call one another at runtime.

Architects shouldn’t constantly seek out silver-bullet solutions to their problems; they are as rare now as in 1986, when Fred Brooks coined the term: There is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliabilit

High functional cohesion refers structurally to the proximity of related elements: classes, components, services, and so on. Throughout

Dynamic coupling Represents how quanta communicate at runtime, either synchronously or asynchronously. Thus, fitness functions for these characteristics must be continuous, typically utilizing monitors.

High static coupling implies that the elements inside the architecture quantum are tightly wired together, which is really an aspect of contracts.

Building services that model bounded contexts required a subtle but important change to the way architects designed distributed systems because now transactionality is a first-class architectural concern. In many of the distributed systems architects designed prior to microservices, event handlers typically connected to a single relational database

All things are poison, and nothing is without poison; the dosage alone makes it so a thing is not a poison. Paracelsus