Why does building on a blockchain call for its own design patterns, and how are they grouped?
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:
| Category | What its patterns handle |
|---|---|
| Interaction with the external world | Getting real-world data and legal meaning in and out of a sealed chain |
| Data management | What data lives on-chain vs off-chain, and how it's protected |
| Security | Authorising actions and treating recent history as final |
| Contract structural | Structuring smart-contract code for upgradeability and control |
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.