1 Data Oriented Programming

Data-oriented programming centers software design on the meaning and representation of data itself. Instead of starting from objects and behaviors, it asks “What is it?” before “What does it do?” and models domain information as explicit, standalone values whose shape communicates intent. Objects aren’t discarded; they’re repositioned as tools for boundaries, orchestration, and resource management, while the core semantics live in data. With precise representations, programs become smaller, clearer, and easier to reason about because the code directly states its meaning rather than leaving it implicit or scattered across callers and comments.

The chapter’s central argument is that good representations eliminate illegal states and the defensive code that guards against them. A simple example replaces an ambiguous String id with a UUID, instantly aligning the type with domain semantics and removing entire classes of errors. A larger example refactors a scheduled task’s implicit state (scheduledAt, attempts) into explicit retry decisions modeled as data (e.g., retry immediately, try later, abandon). This turns guesswork into clear intent, bakes semantic integrity into the code, and lets other parts of the system operate on meaningful signals (e.g., checking for Abandon rather than null). Data orientation and object orientation reinforce each other: expressive domain data can drive clean interfaces (like isAbandoned) while objects manage lifecycles and boundaries.

As models become more precise, the design naturally orients around data: method signatures take and return domain types (e.g., FailedTask to RetryDecision), implementations trend toward expression-oriented transformations, and objects resemble pipelines that vend well-shaped data. This precision also exposes deeper domain distinctions (such as differentiating a ScheduledTask from a FailedTask), creating a feedback loop that sharpens the model. While modern Java features (records, pattern matching, sealed types) make this style pleasant, the approach applies even on older JDKs; tools help, but representation is the essence. The book teaches through small, realistic examples—including “wrong turns”—to cultivate intuition for when modeling choices introduce ambiguity. The takeaway is simple and powerful: get the data representation right and let the simplifications ripple outward through the system.

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