Design Principles and Fundamentals

Welcome to Chapter 3: Design Principles and Fundamentals. Every architecture is built from the same few ideas about structure. How to divide a system into parts, how much those parts should know about each other, which way their dependencies should point, and how to keep the whole thing as simple as the problem allows. This chapter teaches those ideas.

Chapter 2 described the qualities an architecture has to deliver. Most of them, and modifiability above all, depend less on any particular technology than on structure. A team can choose the most fashionable framework and still end up with a system where every change touches ten places. These principles are old ideas. Information hiding dates from nineteen seventy-two, and Conway's law from nineteen sixty-eight. They have survived because they describe something that does not change: the cost of change depends on how far a change has to travel. What has changed is the scale. The principle that tells you to keep a class's fields private also tells you to keep a service's database private. So every section shows each idea twice: in a small piece of code, and at the scale of components and services.

This chapter suits developers who want to reason about design precisely. It also suits architects who need a shared vocabulary for design reviews. Being able to read short Python examples helps. It builds on Chapter 2's quality attributes, which these principles help to achieve. It is worth having read Section zero point three on organising code, and Section two point six on designing for change. And it leads into Chapter 4, which shows how to describe a structure so that others can understand it and challenge it.

The first four sections lay the foundations. Section three point one asks what a module is and where its boundaries should go. David Parnas showed that dividing a system by processing steps fails, and dividing it by likely change succeeds. Section three point two gives you the vocabulary for judging boundaries: the classic levels of coupling and cohesion, and the kinds of coupling that only appear between services. Section three point three looks at the interface itself: information hiding, contracts, abstractions that leak, and why every visible behaviour of a popular interface ends up being depended on. Section three point four turns to direction: which way dependencies should point, how to measure stability, how to break cycles, and how to check all of this automatically.

This diagram from Section three point two shows the vocabulary at work, in a real refactoring. On the left is the design before: an orders module and a billing module. Orders calls Billing directly, passing a flag that selects one of two behaviours. So Orders must know about that flag, and it cannot accept an order if Billing is slow or failing. Worse, both modules use the same orders table. Any change to its layout, its status codes or its VAT rules has to be made in both modules at once. On the right is the design after. Orders publishes an Order Placed event to a message broker, carrying exactly the facts Billing needs. Billing subscribes, and each service owns its own data. The coupling has not vanished: Billing still depends on the meaning of that event. But it is now explicit, narrow and versioned, which is what loose coupling means in practice.

The second four sections build on those foundations. Section three point five covers the five SOLID principles, each shown in code and between services, together with the criticism they attract when applied mechanically. Section three point six introduces connascence, a finer measure of coupling, with a clear set of rules for making it weaker and more local. Section three point seven widens the view to the organisation: Conway's law, the evidence for it, and the arithmetic of communication paths. Section three point eight closes with simplicity and measurement: the complexity that belongs to the problem and the complexity we add ourselves, the price of keeping options open, and the limits of all metrics.

Here is Conway's law in one picture. On the left is an organisation. A checkout team and a catalogue team must go through a shared team of database administrators for every schema change. On the right is the system they build: a checkout service and a catalogue service that both read and write a shared database. The structure of the system copies the structure of communication. So when you design a system, you are also designing who needs to talk to whom, and the reverse is just as true.

Read together, the eight sections make one argument. Change is the dominant cost of software, so a good structure is one in which likely changes stay local. Every principle in the chapter is a way of achieving that. That is also why the principles sometimes conflict, and why none is absolute. The professional skill is to ask, for a change that is likely in this system, how far it would have to travel, and which principle shortens that distance at the lowest cost.

If you are new to design, take the sections in order. Each opens with a short everyday explanation. The whole chapter takes about three hours to read. If you are an experienced engineer, you may prefer to start with the worked examples, such as the online shop in Section three point one, or the metrics calculation in Section three point four. They are designed to be argued with. Each section ends with a few self-check questions. Answer them in your head before you look. When you are ready, take the optional chapter test: twenty multiple-choice questions and two written answers, in about forty five minutes. The pass mark is eighty per cent.

That is the map of Chapter 3. Start with Section three point one, on modularity, where we see how to divide a system so that the changes you expect stay inside one part. See you there.