1 Data Oriented Programming

This chapter introduces data-oriented programming as a pragmatic shift in how we design Java systems: model data “as data,” independent from behavior, so the code itself communicates what things are. By centering representation and semantics—answering “What is it?” before “What does it do?”—programs become smaller, clearer, and easier to reason about. Objects aren’t abandoned; they’re used where they excel (boundaries, resource management, orchestration), while data carries domain meaning directly in the types and values we choose.

A key lesson is that representation drives simplicity. Replacing vague types like String id with a concrete UUID eliminates illegal states and the defensive code that guards against them. The same principle scales to richer domains: instead of implicit state juggling (e.g., scheduledAt and attempts toggled through conditionals), model explicit domain facts as data—such as RetryImmediately, ReattemptLater, and Abandon—to bake semantic integrity into the code. This makes intent self-evident in both implementations and call sites, and it complements object-oriented design by letting clear data models naturally shape interfaces (e.g., isAbandoned or a status field) rather than hiding meaning behind incidental state.

As systems orient around data, methods evolve into pipelines that take data in and return data out, with expressive signatures (e.g., reschedule(FailedTask) -> RetryDecision) and expression-oriented bodies that emphasize clarity over control flow. Focusing on data uncovers deeper domain distinctions (ScheduledTask vs FailedTask vs CompletedTask), guiding better boundaries and reducing ambiguity across the codebase. While modern Java features (records, pattern matching, sealed types) ease this style, the approach is tool-agnostic and viable on older JDKs. The book teaches through compact, real-world examples—including intentional missteps—to build intuition for spotting weak representations and refactoring toward explicit, self-describing data that lets the rest of the design fall into place.

Objects and how they communicate is our focus during object-oriented design

The representation of our data is the primary focus during data oriented design

Being explicit about what a task can transition to after failing

Representing each decision as a piece of standalone data

Focusing on just the data makes us question our representation

clarifying what we’re talking about

Analyzing the data drives a deeper exploration of the domain

How data-oriented programs tend to be shaped

• Data Oriented programming is about programming with data "as data"
• Data is more than just a collection of values. It has an inherent meaning.
• Modeling “data as data” lets us focus on capturing that meaning in isolation from other concerns
• Before asking “what does it do?” data orientation starts a more bedrock question of “what is it?” We want to understand what these things in our domain are at a fundamental level
• Data Orientation is not a replacement for object orientation, functional programming, or any other paradigm. We view all of them as useful tools.
• The representations we choose for our data affects our programs as a whole.
• Good representations eliminate the potential for bugs by making it impossible to create invalid data
• Bad representations introduce problems which ripple outward through our codebase and force us to spend effort working around them
• We can replace reasoning about what vague variable assignments mean by representing that meaning with a concrete data type
• Focusing on the data inside of our objects, rather than just the interfaces, makes our objects as a whole more understandable
• When we do a good job of modeling the data, the rest of the code will feel like it’s writing itself. We just have to follow where the data leads
• Data-Oriented programs tend to be built around functions that take data as input and return new data as output
• We’ll use Java 21 throughout the book (though, you can still follow along with Java 8)

FAQ