The Six Patterns That Cover Everything
Source: Dev.to
The Complete Vocabulary
Every data transformation you’ll ever write falls into one of six patterns:
| Pattern | Description |
|---|---|
| Leaf | One thing. No sub‑steps. Atomic. |
| Sequencer | This, then that. Output becomes input. |
| Fork‑Join | These together, then combine. Independent operations merging. |
| Condition | Which path? Route based on value. |
| Iteration | Same thing, many times. Transform a collection. |
| Aspects | Wrap it. Add retry, timeout, logging around an operation. |
That’s it. Six patterns. They cover everything—not “most cases”, not “common scenarios”. Every piece of request‑processing logic you’ll ever write is one of these six, or a composition of them.
These aren’t design patterns someone invented; they’re the fundamental ways data can flow:
- Transform a value – Leaf
- Chain dependent transforms – Sequencer
- Combine independent transforms – Fork‑Join
- Choose between transforms – Condition
- Apply a transform to many values – Iteration
- Enhance a transform – Aspects
There is no seventh option. Data either transforms, chains, combines, branches, iterates, or gets wrapped. That’s the complete set of possibilities.
Why learning six patterns gives you everything
Not because a particular framework is comprehensive, but because reality is constrained.
How the Same Six Patterns Describe Every Business Process
Think about any workflow in your domain:
| Pattern | Business‑process example |
|---|---|
| Leaf | “Validate the email format” – one atomic check |
| Sequencer | “First verify identity, then check permissions, then grant access” – a dependent chain |
| Fork‑Join | “Get user profile, account balance, and recent transactions, then build the dashboard” – independent data gathering |
| Condition | “If premium user, apply discount; otherwise, standard pricing” – routing |
| Iteration | “For each item in cart, calculate tax” – collection processing |
| Aspects | “Log every payment attempt” – cross‑cutting concern |
Business processes and code patterns use the same vocabulary. This isn’t a coincidence; both describe how information flows and transforms. Business logic is data transformation—we just use different words for it.
The Precision Gain
| Vague wording | Precise pattern‑based wording |
|---|---|
| “Get the user’s stuff and show it” | Fork‑Join: fetch profile, preferences, and history in parallel, then combine into dashboard view |
When a developer asks “Can these operations run in parallel?” they’re really asking “Do these steps depend on each other’s results?”
When business says “First we verify, then we process, then we notify” – that’s a Sequencer, directly translatable to code.
| Business phrase | Pattern | Typical code construct |
|---|---|---|
| “Check if …” | Leaf | Single validation |
| “First … then … then …” | Sequencer | .flatMap() chain |
| “Get X and Y and Z, then …” | Fork‑Join | Promise.all() |
| “If … otherwise …” | Condition | Ternary / switch |
| “For each …” | Iteration | .map() / loop |
| “Always log / retry / timeout …” | Aspects | Wrapper function |
No translation layer, no impedance mismatch. The same six concepts, different vocabulary.
Using the Patterns to Surface Gaps
When you model business processes with these patterns, missing pieces become obvious.
| Pattern | Typical gap questions |
|---|---|
| Leaf / Validation | How do we know this request is valid? What makes an email/phone/amount valid in your domain? |
| Sequencer | What do we need from step 1 to perform step 2? Can step 3 happen if step 2 fails? |
| Fork‑Join | Do these operations depend on each other? Can we fetch profile while also fetching orders? What do we do if one succeeds and another fails? |
| Condition | What determines which path we take? Are the paths mutually exclusive? Is there a default path? |
| Iteration | Do we process all items or stop at the first failure? Does order matter? Can items be processed independently (in parallel)? |
| Aspects | Should we retry on failure? How many times? Is there a timeout? What needs to be logged/measured? |
If a required answer isn’t defined, you ask the question. The patterns generate the right questions automatically.
Forward Flow
- Business describes a process.
- You identify the patterns.
- You implement the code.
Backward Flow (often underrated)
- You see the patterns in a description.
- You notice missing pieces.
- You ask clarifying questions.
- Business refines the process.
- The implementation becomes cleaner and more robust.
Developers who think in patterns become process consultants: they don’t just implement what they’re told—they improve it by making implicit assumptions explicit.
“You said first A, then B, then C. But B doesn’t use A’s output. Can A and B happen at the same time? That would be faster.”
“You said validate the request. What exactly are we validating? Email format? Email exists? User is active? Each is a separate check.”
“You said handle the error. Which error? Network timeout? Invalid data? User not found? Each might need different handling.”
The patterns force precision. Vague requirements become concrete when you have to place them in one of six boxes.
When Developers and Business Share This Vocabulary
- Requirements discussions become technical design sessions.
- Gaps surface during conversation, not during implementation.
- Code structure mirrors the business process (because they’re the same thing).
- Changes in business logic map directly to change‑requests in code.
TL;DR
- There are only six fundamental data‑flow patterns: Leaf, Sequencer, Fork‑Join, Condition, Iteration, Aspects.
- Everything you write—or any business workflow you describe—fits into one of them (or a composition).
- Learning and using these six patterns gives you a complete, shared language between developers and stakeholders, eliminates ambiguity, and makes both design and implementation dramatically more precise.
Process Map Directly to Code Changes
- New team members understand both business and code faster.
- Six patterns. Complete coverage. Shared language. Gap detection built‑in.
This is why pattern‑based thinking isn’t just a coding technique. It’s a communication framework that makes the implicit explicit and the vague precise.
The irony? You’ll spend an hour asking the right questions. The coding takes 30 seconds. Turns out the “coding technology” is mostly about not coding.
Part of Java Backend Coding Technology – a methodology for writing predictable, test‑able backend code.
Previous: The Underlying Process of Request Processing