Code design

Patterns-oriented design is one of the three attitudes this hub is built on. This section is its vocabulary.

A pattern is a named solution to a recurring problem, together with the forces that make it the right answer. The name is doing most of the work: it lets two developers discuss a design in five words instead of fifty, and it lets a codebase be read by someone who did not write it.

The five catalogues

Catalogue	Scale	The question it answers
GoF patterns	Within a module	How should these classes relate?
Tactical DDD patterns	Within a bounded context	What is this concept, and what is it called?
Architecture patterns	Within a system	Where do the boundaries go, and what may cross them?
Integration patterns	Between systems	How do two things that fail independently talk?
Use case patterns	At the application boundary	What shape does one unit of business work take?

The one that is different

Four of these change how code is structured. The tactical DDD catalogue also changes what it is called — the class names, the method names and the package tree come from the language the business already speaks, rather than from the framework or the schema. That gives it the widest blast radius of the five: a structure is read at review time, a name is read every day.

It is the developer’s half of the DDD practice, whose other half — subdomains, bounded contexts, context maps — is decided in a room with domain experts before any of this applies.

Vocabulary, not a shopping list

The failure mode is universal and worth naming: a developer learns the catalogue, then goes looking for places to apply it. The result is a codebase with a factory producing one type, a strategy with one implementation, and an observer with one listener — layers of indirection paid for in advance against flexibility that never arrives.

The rule that avoids it: have the problem first. A pattern applied to a problem you do not yet have is not preparation, it is speculative complexity, and it costs the same as the real thing while buying nothing.

Each entry carries its cost

Every pattern page here states what the pattern buys, what it costs, and when not to use it. A catalogue that only lists benefits teaches developers to over-apply, which is precisely how patterns acquired their bad reputation in the first place.

Hygiene

Patterns are usually taught as a design activity, done at design time. Most of their value is collected somewhere else entirely: in the ordinary, unglamorous upkeep of code that already exists. That upkeep deserves a name — hygiene — and it is five habits, none of them heroic, all of them cheap when done continuously and expensive when deferred:

Naming. The name says what the class holds; the class holds what the name says. Divergence between the two is the earliest defect to appear in a codebase and the cheapest to fix, and it is the one most reliably ignored because nothing fails when it is wrong.

Balancing. Responsibility spread across the classes of a package rather than collected in one of them. The check is a directory listing: one 400-line file beside nine 12-line files is not a package, it is a class with attendants. This is worked through under use case patterns.

SRP. One reason to change. It is the lever behind testability — the mechanism is set out under test-first — and balancing is what it looks like once a package rather than a class is in view.

OCP. New behaviour arrives as a new implementation rather than as an edit to an existing switch. Achievable only where the seam already has a name, which is what these catalogues supply; without one, “open for extension” is a wish.

Pattern language. The shared vocabulary itself, including the stereotype names — service, strategy, converter, listener, handler, mapper, processor, client, controller — used consistently enough that a suffix is a promise rather than a decoration.

The fifth habit is what makes the other four enforceable. Naming, balancing, SRP and OCP are all judgements about whether a class does one recognisable thing, and recognisable presupposes a vocabulary of things to recognise. Without it, each of the four is a matter of taste, and taste loses every argument it has with a deadline.

The connection to craftsmanship

Software craftsmanship makes us question the relevance of a line of code, its purpose, its location, its testability and its durability. Patterns are how those questions get answered at the level of structure rather than the level of the line — and how the answer is communicated to whoever reads the code next.

Status

The tactical DDD page is written out with examples. The other four state their scope, their selection principle and their main entries, each with a worked example of the entry that is most often got wrong; the full per-pattern pages, with a rendering per stack, are not written yet.