Because a blockchain is a shared, immutable, self-contained data-and-compute layer with real limits (no privacy, low throughput, no reach outside itself), so architects need reusable solutions — grouped into interaction-with-the-external-world, data-management, security, and contract-structural patterns.

* The pattern collection at a glance — 15 patterns in 4 families. *

A design pattern is a reusable solution to a problem that recurs in a given context. Blockchain has unusual properties — every node keeps a full replica, stored data can't be revised, code runs without a central operator — and matching limitations: poor privacy, poor performance, and a sealed execution environment. Naively bolting an app onto a chain fights those properties. The collection organises fifteen patterns into four families:

The point is anti-hype engineering: use the chain's strengths, work around its limits.

Go deeper:

• An Extended Pattern Collection for Blockchain-based Applications (arXiv, Xu, Pautasso et al.) — the authors' open-access, extended write-up of this exact pattern collection, with the full problem/solution/consequence structure for every pattern.
• Blockchain (Wikipedia) — the underlying properties (replication, immutability, decentralised consensus) that make these patterns necessary in the first place.

Deciding what data and executable code stays on-chain versus off-chain — forced because a smart contract is a pure function that cannot read anything outside the chain, and because on-chain storage and computation are scarce and expensive.

A smart contract is code deployed on the chain that runs when a transaction triggers it and records its result in shared state. By design these are pure functions: they can only see data already on the chain and cannot reach out to a web API, a sensor, or a database. On top of that, every participant stores a full replica, so on-chain storage is limited and (on public chains) costs real money, and throughput is low. So for every piece of an application you must choose:

• On-chain — trustless, immutable, publicly verifiable, but scarce, slow, and public.
• Off-chain — cheap, fast, private, but not covered by the chain's guarantees.

Two forces dominate the choice: performance (heavily dependent on the deployment type) and privacy. Most of the pattern collection exists to bridge this on-chain/off-chain gap cleanly.

Go deeper:

• Smart contract (Wikipedia) — how contract code executes deterministically on-chain, and why it is sealed off from external state and I/O.