1 Data Oriented Programming

Data-oriented programming centers software design on the meaning of data itself. Instead of hiding information behind objects and behaviors, it first asks “What is it?” and represents that answer explicitly and precisely in code. Objects are not discarded—they remain invaluable for managing stateful resources and enforcing boundaries—but they are treated as tools that sit atop a clear, self-describing data model. By elevating data and choosing faithful representations, programs become smaller, simpler, and easier to understand.

The chapter shows how representation reshapes systems, from a single variable to an entire workflow. Replacing an ambiguous “String id” with a “UUID” moves semantics into the type system, eliminating illegal states and the defensive code that guards against them. At a larger scale, implicit state (like loosely related fields) is refactored into explicit, standalone data that names domain concepts directly—for example, modeling retry outcomes as concrete decision data rather than inferring meaning from field combinations. This bakes semantic integrity into the codebase, reduces guesswork for readers, and complements object-oriented interfaces by making intent obvious and verifiable.

As designs orient around data, method signatures and control flow evolve naturally: functions take domain data in and return domain data out, favoring expression-oriented style and pipeline-like composition. Clarifying lifecycle states (e.g., scheduled, failed, completed) deepens the model and sharpens boundaries, letting objects “fall into place” as providers and orchestrators of data. While the book leverages modern Java features (records, pattern matching, sealed types), the approach is JDK-agnostic; the teaching uses small, realistic examples—including deliberate missteps—to build intuition. The core takeaway: precise, explicit representations make meaning visible, and when meaning is visible, designs become obvious.

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