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...

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...