A good cheatsheet does not replace judgment. It shortens the path back to the right judgment.

This page is the compact reference map for the whole OOAD vertical. It is designed for quick recall during design reviews, refactoring sessions, architecture discussions, and interviews. Instead of repeating every detail from the full pages, it tells you what each major pattern family is for, when it usually fits, and what nearby concepts to compare before deciding.

OOAD landing page Learning roadmap Next: Architectural Styles Comparison

Why This Topic Matters

Why it matters in real Java systems

Once teams learn many patterns, the next problem is recall under pressure. A strong reference page helps developers remember whether they are facing a variation problem, a boundary problem, a workflow problem, a distributed consistency problem, or an execution problem before they reach for implementation details too early.

Core Explanation

The main reference idea

Think of this page as a lens selector. GoF patterns help with object collaboration and structure. J2EE patterns help with enterprise layering and boundary management. DDD patterns help with model integrity and business language. Microservices patterns help with distributed ownership and resilience. Concurrency patterns help with timing, scheduling, and state safety.

The fastest way to use the cheatsheet is to identify the dominant pressure in the design: changing algorithms, coordination between objects, layering and transport boundaries, domain ambiguity, cross-service consistency, or overlapping execution. Then follow the linked deeper page from the family that actually matches that pressure.

Concept Breakdown

Key ideas to keep in mind

Reference

Structural pressure

Use GoF and OOAD principles when the main problem is object collaboration, substitution, or boundary shape.

Reference

Enterprise pressure

Use J2EE and architecture pages when the main problem is layering, transport, orchestration, or system composition.

Reference

Runtime pressure

Use microservices and concurrency pages when the hard part is failure, scheduling, throughput, or coordination over time.

Quick pattern family table

Family	Use it when	Start with
GoF	You need better object structure, delegation, variation control, or composition	Strategy, Adapter, Factory Method, Decorator
J2EE / Jakarta EE	You need presentation, business, or integration boundary patterns	Front Controller, Application Service, DAO
DDD	The real difficulty is business language, context boundaries, and model correctness	Bounded Contexts, Aggregates, Domain Events
Microservices	The system has earned distributed boundaries and now needs consistency and resilience patterns	Saga, Outbox, Database per Service
Concurrency	The hard part is safe overlapping work, contention, and execution control	Thread Pool, Producer-Consumer, Monitor Object

Java Example

Java example in the Order Management domain

Java example: a compact family selector for design review

package org.javaomnibus.reference;

public final class DesignPressureGuide {
    public String recommend(String pressure) {
        return switch (pressure) {
            case "variation" -> "Start with GoF patterns";
            case "enterprise-boundary" -> "Start with J2EE and architecture pages";
            case "domain-complexity" -> "Start with DDD";
            case "distributed-consistency" -> "Start with microservices patterns";
            case "execution-and-contention" -> "Start with concurrency patterns";
            default -> "Start with OOAD principles and the roadmap";
        };
    }
}

Code Walkthrough

Step by step

The example is intentionally simple: the real value is the mental classification, not the code itself.
A cheatsheet is useful when it helps the team categorize the problem before they jump into libraries or syntax.
That makes the larger vertical easier to navigate under real project pressure.
This page acts as the final quick-reference index for everything that came before it.

Real-World Usage

Where this helps in practice

Architecture workshops
Interview preparation and revision
Refactoring sessions where the team needs fast pattern recall

Trade-Offs

Trade-offs and when to be careful

A cheatsheet speeds recall, but it can oversimplify if treated as a substitute for the deeper pages.
The best use is navigation and comparison, not pattern selection by slogan.

Common Mistakes

Frequent mistakes to watch for

Using pattern names without checking the actual design pressure
Treating all patterns as equally heavyweight
Confusing quick reference with architectural reasoning
Skipping trade-offs because the cheatsheet looked convenient

Related concepts

GoF overview and catalog Architectural styles overview Concurrency overview