Architecture Primitives

An architect who knows many patterns is less useful than one who knows when each pattern is wrong.

For each primitive: what it is, when to use it, and when it will hurt you.

Boundaries and Ownership

What it is. Drawing lines between components so each has a clear owner, clear interface, and can evolve independently.

When it's right. When different teams own different parts. When components have different scaling, deployment, or reliability requirements. When you need to limit blast radius.

When it's wrong. When the "boundary" creates more cross-boundary coordination than it prevents. When data that changes together is split across boundaries. When the team is small enough that communication overhead exceeds boundary value.

Contracts and Interfaces

What it is. Explicit agreements between components about what they provide and expect — API schemas, message formats, SLAs, error codes.