1 Data Oriented Programming

Data-oriented programming centers software design on explicitly modeling “what the data is” rather than hiding it behind behavior. It does not reject objects; instead, it reframes them as tools for boundaries, lifecycle, and coordination while keeping the core domain concepts represented as plain, descriptive data. By making representation the primary design pressure, code becomes smaller, clearer, and more self-explanatory, shifting our thinking from “what does it do?” to the more fundamental “what is it?”

A small but telling example is an identifier modeled as a String versus a UUID. The String form is ambiguous and invites an infinite number of illegal states, forcing scattered checks and defensive code. Replacing it with UUID moves the semantics into the type system, making the code self-describing, eliminating bad states at construction time, and reducing incidental complexity and tests. This “obvious but underused” act of tightening representation is the essence of the approach: align types with meaning to let the code communicate directly.

A larger example shows how implicit object state (e.g., attempts and scheduledAt) obscures meaning and breeds semantic drift. Modeling the possible retry outcomes explicitly—RetryImmediately, ReattemptLater, Abandon—turns hidden conventions into first-class data, improving readability, enforcing semantic integrity, and simplifying downstream usage (e.g., pruning by status instead of null checks). Combined with object-oriented interfaces, this yields expressive method signatures and data-in/data-out pipelines that feel inevitable. Modern Java features (records, pattern matching, sealed types) help, but the ideas work back to Java 8. Throughout, the book teaches with focused examples (including wrong turns) to build intuition that better data representation lets the rest of the design fall naturally into place.

Objects and how they communicate is our focus during object-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

• Data Oriented programming focuses on representing data "as data"
• Data Orientation does not replace object orientation. The two work together
• In OOP, the interfaces between objects are primarily where we improve designs.
• In DOP, the representation of data is where we improve designs
• While OOP primarily asks “what does it do?”, DOP asks “what is it?”
• To quote Fred Brooks, “data is the essence of programming”
• The types we pick to represent data have a giant effect on our programs
• The wrong data representation allows illegal states to exists.
• The right data representation makes illegal states impossible to express
• A lot of what makes reading code hard is understanding the original author’s intentions
• DOP gets rid of “If X is set then it means…, but if Y is set then …” code ambiguities
• Use concrete data types to represent the meaning behind variable assignments
• Focusing on data leads to “Aha!” moments that deepen your understanding of a domain
• instanceOf is perfectly fine when used with data. The object rules do not apply
• Combining DOP with OOP makes your objects more descriptive and easier to understand
• Code naturally begins to “orient” around a good data model.
• Objects emerge around data in a way that feels inevitable.
• Good data models extends to how we design methods
• void, zero argument methods are an informational black hole.
• Make methods show what they do by using descriptive inputs and return types
• Each chapter in this book will work through a unique example
• All examples in this book are pulled from the real world. You’ll get to see all my mistakes
• We’ll use Java 21 throughout the book (though, you can still follow along with Java 8)

FAQ