
Software Architecture: The Hard Parts

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
... See moreNeal Ford • Software Architecture: The Hard Parts
An architect implements fitness functions to build protections around unexpected change in architecture characteristics. In the Agile software development world, developers implement unit, functional, and user acceptance tests to validate different dimensions of the domain design. However, until now, no similar mechanism existed to validate the arc
... See moreNeal Ford • Software Architecture: The Hard Parts
Static coupling Represents how static dependencies resolve within the architecture via contracts. These dependencies include operating system, frameworks, and/or libraries delivered via transitive dependency management, and any other operational requirement to allow the quantum to operate.
Neal Ford • Software Architecture: The Hard Parts
Each understands the common scope under question: architects understand the coupling characteristics, developers understand the scope of behavior, and the operations team understands the deployable characteristics.
Neal Ford • Software Architecture: The Hard Parts
Often, the best design an architect can create is the least worst collection of trade-offs—no single architecture characteristics excels as it would alone, but the balance of all the competing architecture characteristics promote project success.
Neal Ford • Software Architecture: The Hard Parts
Architects must watch out for composite architecture characteristics—ones that aren’t objectively measurable but are really composites of other measurable things. For example, “agility” isn’t measurable, but if an architect starts pulling the broad term agility apart, the goal is for teams to be able to respond quickly and confidently to change, ei
... See moreNeal Ford • Software Architecture: The Hard Parts
An architecture quantum is an independently deployable artifact with high functional cohesion, high static coupling, and synchronous dynamic coupling. A common example of an architecture quantum is a well-formed microservice within a workflow.
Neal Ford • Software Architecture: The Hard Parts
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.
Neal Ford • Software Architecture: The Hard Parts
static coupling analyzes operational dependencies, and dynamic coupling analyzes communication dependencies.