Patterns

Making the relationships between bounded contexts, and the teams that own them, explicit, so that integration between separate models is a deliberate design choice rather than an accident. Domain Driven Design names the relationship types (shared kernel, customer/supplier, con...

Keeping software in a continuously releasable state, so that shipping to users is a routine, low risk, on demand event rather than a painful, infrequent project. It is assembled from working in small batches, automating the build test deploy path so quality is built in rather...

Weaving the work of deciding what to build into the team's regular cadence rather than running it as an upfront phase: staying in frequent contact with customers, framing their needs as opportunities, mapping opportunities to candidate solutions, and testing the riskiest assum...

A deliberate practice for correcting predictable errors of judgment: slow down to engage reflective thinking, start from the outside view, reason in probabilities, seek the case against your own conclusion, update as evidence arrives, and keep score so the practice can improve...

Designing systems so that errors are hard to make, structurally prevented where they are costly, and easy to recover from where they slip through. It treats error as a property of the design rather than a failing of the user, combining the elimination of error conditions, cons...

Drawing the lines between parts of a system, in code and in the organization, so that each part hides its internals behind a simple interface and can be understood and changed on its own. The same principle governs a module's boundary and a team's boundary. Deep Modules — make...